Dual-layer multi-zone blockchain system

Abstract

The present invention relates to blockchain technology, and in particular to a dual-layer multi-zone blockchain system, comprising a plurality of consensus zones and a coordination layer. Each consensus zone comprises a plurality of zone nodes and a DAG node; each consensus zone maintains a blockchain; zone nodes and a DAG node in each consensus zone are all smart terminals having a computing capability and a communication capability; the zone nodes participate in the competition for blockchain block generation of the consensus zone, and the DAG node does not participate in the blockchain block generation of the zone; DAG nodes of all the zones form the coordination layer, and the DAG nodes forward to the coordination layer blocks generated by the zones; the coordination layer maintains a DAG-based main chain ledger, and a DAG ledger in DAG consensus is composed of the blocks generated by all the zones. In the present invention, a stable and personalized application can be established in each zone, and user privacy and data permission protection are provided for each zone, so that the performance and security are ensured while the expandability is improved.

Description

A two-layer multi-partition blockchain system Technical Field

[0001] The present invention relates to blockchain technology, and in particular to a double-layer multi-partition blockchain system. Background Art

[0002] Existing blockchain deployments often face the trilemma of scalability, security, and decentralization. Sharding, a promising solution to address scalability limitations and resource efficiency, is to partition the workload into multiple domains. These shards typically operate in parallel, maintaining different blockchains under the same consensus. Performance (i.e., throughput) scales linearly with the number of shards, reducing the communication, computation, and storage load on each blockchain node.

[0003] Based on this idea, many sharding-based blockchains have been proposed. Loi Luu, Viswesh Narayanan, and others proposed a layered blockchain architecture called Elastico at the 2016 ACM SIGSAC Conference on Computer and Communications Security. With the addition of shards, block generation speeds are several orders of magnitude faster than Bitcoin. However, in terms of resource efficiency, since all nodes need to store the entire distributed ledger, communication and storage efficiency are very low. Furthermore, the low percentage of malicious nodes supported poses security issues. Furthermore, the inability to guarantee the atomicity of cross-chain transactions is a major limitation of this architecture.

[0004] At the 2018 IEEE Security and Privacy Symposium, Eleftherios Kokoris-Kogias et al. proposed the OmniLedger architecture. This architecture increases block production linearly with the number of shards, distributing the storage burden across each shard and achieving high resource efficiency. However, due to its low support for malicious nodes, it also faces security issues and is limited to consensus within each shard.

[0005] At the 2018 ACM SIGSAC Conference on Computer and Communications Security, Mahdi Zamani, Mahnush Movahedi, and others published a paper describing a RapidChain architecture that offers better scalability than OmniLedger and improved security, but lacks flexibility in selecting the consensus mechanism for each shard.

[0006] At the 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), Jiaping Wang and Hao Wang proposed the Monoxide architecture. This sharded blockchain architecture significantly improves security, but suffers from low resource efficiency and inflexible selection of the consensus mechanism for each shard.

[0007] In summary, existing blockchain constraints face the following difficulties:

[0008] 1) Scalability is determined by throughput and resource efficiency, where throughput is measured as the total block generation rate increases with the number of shards, and resource efficiency is measured as the proportion of the total ledger stored and processed by each node;

[0009] 2) Security is measured by the ratio of the number of malicious nodes allowed in each shard to the total number of nodes in all shards;

[0010] 3) Decentralization is determined by whether it relies on a trusted intermediary or a dedicated blockchain.

[0011] Summary of the Invention

[0012] In order to solve the problem of reduced security caused by partitioning in the application of blockchain technology, while improving security, the present invention ensures the scalability of the blockchain architecture. A two-layer multi-partition blockchain system is proposed. The system includes multiple consensus partitions and a coordination layer. Each consensus partition includes multiple partition nodes and a DAG node. Each consensus partition maintains a blockchain. The partition nodes and DAG nodes in each consensus partition are intelligent terminals with computing and communication capabilities. The partition nodes participate in the competition for the generation of the consensus partition blockchain block, and the DAG nodes do not participate in the generation of the partition blockchain block. The DAG nodes of all partitions constitute the coordination layer. The DAG nodes forward the blocks generated by the partition to the coordination layer. The coordination layer maintains a main chain ledger based on DAG, and the DAG ledger in the DAG consensus is composed of blocks generated by all partitions.

[0013] Furthermore, each consensus partition uses a different consensus algorithm.

[0014] Furthermore, the information type included in the block generated by each partition is expressed as:

[0015] {height,zoneIntra,hashIntra,txIntra,zoneInter,hashInter,txInter}

[0016] Among them, height is the block height of the distributed ledger maintained by the current consensus partition; zoneIntra represents the partition node that generates the current block; hashIntra represents the hash value of the current block linked to the block in the current consensus partition; txIntra represents the transaction input in the consensus partition zoneIntra and output in the consensus partition zoneIntra; zoneInter represents a consensus partition other than the current block; hashInte represents the hash value of the current block linked to the block in the consensus partition zoneInter; txInter represents the transaction input in the consensus partition zoneIntra and output in the partition node zoneInter.

[0017] Furthermore, when generating a block, the partition node uses the hash value of the generated block and the block at the end of the main chain in the blockchain it maintains as the hashIntra of the current block; the DAG node of the current partition selects a hash value of a block that has not been selected and generated for other consensus partitions from the DAG-based main chain ledger it maintains as the hashInte of the current block.

[0018] Furthermore, the new block searches for historical key-pair values ​​based on the height of the current block. If the height exists in the historical key-pair value, the parameters at the height are called to generate the block. Otherwise, the Markov Chain Monte Carlo algorithm is used to obtain parameters from the local ledger of the blockchain. A historical key-pair value is represented as (height, {hashInter, zoneInter}), and there is only one historical key-pair value at the same height in the same partition.

[0019] Furthermore, the process of obtaining hashInter and zoneInter from the local ledger of the blockchain using the Markov Chain Monte Carlo algorithm includes:

[0020] Select blocks with higher weights from each partition as starting blocks, and place a particle on each block;

[0021] The block in other partitions that can be selected as the current block is used as the target block, and the block that can directly or indirectly prove the current block is used as the relay block, so that the particles on the starting block perform random walk;

[0022] The partition where the particle that first reaches the destination block arrives is used as the zoneInter of the current block, and the hash value of the destination block is used as the hashInter of the current block.

[0023] Furthermore, the partition main chain is updated, that is, the block with the highest height and the largest cumulative weight in the current partition is ensured to be on the same chain as the most recently generated block in the current partition, and this chain is used as the main chain of the partition.

[0024] The present invention utilizes DAG master nodes and partition nodes to form a two-layer partitioned blockchain system architecture. Under the two-layer multi-partition architecture, stable and personalized applications can be established in each partition, providing user privacy and data permission protection for each partition, while improving scalability while ensuring performance and security. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] FIG1 is a schematic diagram of the architecture of a double-layer multi-partition blockchain system according to the present invention;

[0026] FIG2 is a workflow of a double-layer multi-partition blockchain system according to the present invention;

[0027] Figure 3 shows scenarios in which the system of the present invention can be applied, where (a) is scenario 1, (b) is scenario 2, and (c) is scenario 3;

[0028] FIG4 is a schematic diagram showing the relationship between block height and average targetHash in the system of the present invention;

[0029] FIG5 shows the relationship between the effective block output speed and the number of partitions n in the system of the present invention;

[0030] FIG6 is a block node connection diagram in a preferred embodiment of the present invention;

[0031] FIG. 7 is a schematic diagram showing the update of the cumulative weight after the graph block X passes the verification in the present invention. DETAILED DESCRIPTION

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

[0033] The present invention proposes a two-layer multi-partition blockchain system, which includes multiple consensus partitions and a coordination layer. Each consensus partition includes multiple partition nodes and a DAG node. Each consensus partition maintains a blockchain. The partition nodes and DAG nodes in each consensus partition are intelligent terminals with computing and communication capabilities. The partition nodes participate in the competition for generating blocks of the consensus partition blockchain, and the DAG nodes do not participate in the generation of blocks of the partition blockchain. The DAG nodes of all partitions constitute a coordination layer. The DAG nodes forward the blocks generated by the partition to the coordination layer. The coordination layer maintains a main chain ledger based on DAG, and the DAG ledger in the DAG consensus is composed of blocks generated by all partitions.

[0034] This embodiment first explains the DAG principle.

[0035] Transactions issued by nodes constitute the node set of the DAG graph, the ledger that stores transactions. A directed edge set is obtained by selecting two previous transactions when a new transaction arrives. This process is represented in the DAG graph as directed edges, with the new transaction pointing from the old one to the new one. If there is no directed edge between transactions A and B, but there is a directed path of at least 2 from A to B, we say that A indirectly verifies B. To ensure that no entity can generate a large number of transactions with "verifiable" weight in a short period of time, the weight of a transaction is proportional to the amount of work performed to issue the transaction. The cumulative weight of a transaction is the sum of its weight and the weights of transactions that directly or indirectly verify it. Generally, to issue a valid transaction, a node must select a certain number of non-contradictory transactions and then sign them using cryptographic methods. A successfully issued transaction will not be confirmed until its cumulative weight reaches a pre-set threshold. For example, transaction F is directly or indirectly selected by transactions A, B, C, and E. F's own weight is 3, and the cumulative weights of A, B, C, and E are 1, 3, 1, and 1 respectively. The cumulative weight of F 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.

[0036] In this paper, a tip is defined as an unselected transaction in the DAG graph. For a node in the DAG, its height refers to the length of the longest path toward the origin, and its depth refers to the length of the longest reverse path to a tip.

[0037] This embodiment proposes a two-layer partitioned blockchain architecture, which mainly includes multiple consensus partitions and a coordination layer, as shown in Figure 1.

[0038] 1. Consensus Partition

[0039] All device nodes in the system are divided into different consensus partitions. Nodes within a partition need to reach a consensus. In this way, each partition maintains its own ledger and can form a multi-chain system through multi-partition connection. Therefore, the work of competing block packaging and transaction confirmation can be carried out separately and in parallel, thereby maintaining a stable block production speed and solving the problem of excessive resource consumption caused by block generation.

[0040] 2. Coordination layer

[0041] To coordinate interactions across consensus zones, this embodiment proposes a coordination layer. This layer maintains a DAG-based master ledger to coordinate chain state updates across all zones. While transactions are the fundamental unit of the ledger in traditional DAG consensus, the fundamental unit of the DAG ledger in the dual-layer, multi-zone blockchain architecture proposed in this invention consists of blocks generated across all zones.

[0042] While DAG has demonstrated its potential for scalability, it also faces inherent limitations. For example, the stability and security of system performance are affected by network load. However, by combining the stable block production speed provided by multiple consensus partitions, a scalable, distributed, and stable solution can be achieved. Furthermore, to ensure the security of each partition, an improved main chain determination algorithm is employed. The main chain of each partition is determined based on the cumulative weight of the DAG ledger. Therefore, what prevents data tampering in each chain is not the individual nodes dispersed within the partition, but the cumulative competitive power of honest nodes across all partitions. In other words, the two-layer, multi-partition blockchain architecture makes attacking a single partition as difficult as attacking the entire blockchain system.

[0043] DAG nodes (DAG Maintainer, DM) and partition nodes (Chain Maintainer, CM) play a key role in the two-layer multi-partition architecture. As shown in Figure 1, DAG nodes do not participate in the competition for block generation, but relay the blocks generated in each partition. The DAG main chain is stored and maintained by DAG nodes. N = {1, 2, ..., n} is represented as a partition set. In each partition, there must be only one DAG node DM. i (where i∈N) acts as a hub connecting other partitions, which can be updated based on bias-resistant public randomness to avoid single point failure and targeted attack problems, through DM={DM1,...,DM i ,...,DM n}A peer-to-peer (P2P) network is formed, and each block generated in partition #i can be propagated to other DAG master nodes.

[0044] Partition nodes are responsible for transaction serialization and block generation. Partition nodes only need to store the partition chain of the partition to which they belong. Partition nodes are divided into multiple partitions using the same consensus algorithm. CM i ={CM ij ∣1≤j≤Z i} represents the set of partition nodes belonging to partition #i, where Z i It's CM iThe size of (where i∈N); when trying to update the ledger of partition #i, they need to select two Tips and store their hash values ​​in the block, one is the hashIntra generated by the node in the partition to generate the block link to the partition chain in the partition, and the other is the DM i The generated hashInter is used to link the generated block to the DAG main chain, using B ij represents the jth block generated in partition #i, B ij Several necessary information types are included in the .

[0045] Table 1 B ij The type of information required to be included

[0046] As shown in Figure 2, the workflow of a two-layer multi-partition blockchain system includes the following steps:

[0047] 1.1 Block Generation

[0048] Through the selected hashIntra and hashInter, blocks can be generated according to the consensus algorithm adopted by the partition.

[0049] According to the Tip Selection Algorithm, a block in one partition is selected as the hashIntra of the new block, and a block in another partition is selected as the hashInter of the new block. Different partitions may run different consensus algorithms, and blocks are generated based on the consensus algorithm used by the partition.

[0050] 1.2 Chain node block verification

[0051] Chain node block verification involves the verification of transactions and blocks, including transaction order, transaction signatures, and the number of transactions included. Block verification verifies whether the generated blocks comply with the blockchain rules of the partition, performing block size verification, block order verification, etc. Chain node block verification varies depending on the consensus of different chains to ensure the consistency of blocks generated within the partition and the legitimacy of transactions.

[0052] 1.3 Partition Main Chain Update

[0053] Main chain determination is a key step in partition main chain update, which determines whether the block is in the main chain. i (i∈N) compared to CM i Only information within partition #i can be obtained, so it is necessary to rely on DM iCooperate with other partitions to determine the partition main chain. The main chain determination strategy in the present invention is: ensure that the block with the highest height and the largest cumulative weight in the current partition is on the same chain as the latest block generated in the current partition, and use this chain as the main chain of the partition; in this embodiment, ensure that the block with the highest height and the largest cumulative weight in the current partition is on the same chain as the latest block generated in the current partition, and use this chain as the main chain of the partition.

[0054] DAG master nodes have limited authority: DAG master nodes have absolute authority in this process, which will easily lead to the formation of centralized master nodes. To address this issue, DAG master nodes are set to have only the authority to extend the single chain of the partitioned ledger, rather than roll them back.

[0055] Operation when the DAG master node is not working: There is a possibility that the partition node cannot obtain information from the DAG master node. When the switch to the new DAG master node fails, in order to make the single chain system of partition #i proceed without violating the hashInter of the DAG master node, in addition to meeting the requirements determined by the consensus algorithm main chain adopted by partition #i, the single chain tip of partition #i should also directly or indirectly verify the latest hashInter of the DAG master node within the partition.

[0056] 1.4 Intra-partition Tip selection: Select the tip of the partition main chain, hashIntra is the hash of the tip.

[0057] Based on the partition node main chain determination in the previous step, the partition node can determine the Tip of the partition after obtaining the main chain of the corresponding partition, thereby completing the Tip selection within the partition, and using the hash value of the Tip of the main chain in the selected partition as the hashIntra of the new block.

[0058] 2.1. DAG main chain block verification: DAG block verification is still required before subsequent functions process the received blocks.

[0059] Once the generated or received block meets the verification requirements of the partition node, the received block will be processed in the next step; after the newly generated block passes the block verification within the partition, it needs to be diffused to the upper coordination layer DAG master node for DAG block verification. Based on the single chain information of all partitions and the link information between partitions, the new block is verified to determine whether it is an invalid block.

[0060] 2.2. DAG ledger update: The DAG node determines the blockchain main chain based on the DAG main chain ledger and updates the main chain.

[0061] After the DAG master node verifies the block, it traverses the DAG main chain maintained by the coordination layer's DAG nodes, starting from the starting block, and determines the most heavily weighted block in the partition to the tip to determine the main chain for that partition. This is then passed to the chain node block. It then assists the lower-level partition nodes in updating the partition main chain. Once the main chain is determined, the DAG main chain is updated.

[0062] 2.3 Inter-partition Tip selection: Select the Tip of other partition main chain, hashInter is the hash of the tip.

[0063] When the first layer adopts a proof-based consensus algorithm, two or more partition nodes may generate blocks for the same partition at approximately the same time. Therefore, the fork problem leads to three possible situations where hashInter does not behave maliciously, as shown in Figure 3 (a) to (c). In addition, in order to maintain the DAG state shown in Figure 3 (a), Algorithm 1 is designed to resist the scenarios shown in Figure 3 (b) to (c), where Recent-Selected is a key-value pair set used to store historical selection results. The required DAG state should meet the following two conditions:

[0064] ① CM of the i-th region i∈N i The same applies when selecting other blocks.

[0065] For a specific block height, {hashInter,zoneInter} will only be used by honest DMs. i Once selected, the result will be inserted into Recently-Selected. By maintaining this set, the honest DM i Can be in CM i Maintaining the consistency of {hashInter, zoneInter} responses when requesting inter-zone tip selection and finally performing DAG linking through hashInter can avoid the situation shown in Figure 3(b).

[0066] ②Other partitions are consistent in choosing the same #i partition fork.

[0067] The blocks submitted by different partition nodes in partition #i will be i Out-of-order reception in the first layer, however, this disorder does not make the system unstable because DM i At the second level is the unique source of partition #i, which acts as a hub to connect to other partitions. Therefore, other DAG master nodes will be in DM iBlocks from partition #i with different reception times are received in a consistent order when sent. With the consistent block reception order among honest DAG master nodes, they can reach a consensus on approving the same fork for partition #i. This also avoids the situation shown in Figure 3(c) among honest nodes.

[0068] Specifically, this embodiment also provides a specific implementation method of a two-layer multi-partition blockchain system, including:

[0069] Step 1: Build a two-layer multi-partition blockchain network

[0070] 1.1 Composition of Partitioned Network

[0071] The two-layer, multi-partition blockchain architecture consists of multiple partition networks, which can be written as partition 1, ..., partition i, ..., partition n. It also includes a DAG network running on the upper layer.

[0072] Partition nodes: Each partition may contain a different number of smart terminals with computing and communication capabilities. After two-way verification, each smart terminal can join the group as a node and has the ability to initiate transactions, create transactions, and broadcast externally.

[0073] DAG node: In order to realize the information transmission between partitions and connect each partition, each partition must contain a DAG node DM i (where i∈(0,n]), DAG nodes can be composed of nodes that can provide efficient storage and computing capabilities. The DAG nodes in each partition do not participate in the competition for block generation, but relay the blocks generated in each partition and maintain the DAG main chain.

[0074] 1.2 Build each partition network to ensure normal communication between nodes in each consensus partition

[0075] After nodes within a zone are activated, a peer-to-peer (P2P) network is established within the zone. Devices can connect to each other via wired broadband or wireless communication links. Each zone maintains an independent distributed ledger. Other smart devices can also join the corresponding zone through two-way authentication, becoming new nodes.

[0076] 1.3 Connect DAG nodes, build DAG network, and ensure normal communication between upper and lower nodes

[0077] After establishing a partitioned network, in order to achieve information transmission between partitions, it is necessary to build an upper-level main chain based on DAG consensus. The DAG master nodes DM1, ..., DMi, ..., DMn are responsible for maintaining the main chain and performing asynchronous processing of transactions published by each partition sub-chain.

[0078] Step 2: Generate blocks and update ledgers

[0079] 1.4 Intra-partition Tip selection: Select the tip of the partition main chain, hashIntra is the hash of the tip.

[0080] The DAG consensus mechanism is used in the two-tier, multi-partition architecture to coordinate block generation and ensure transaction security. In this invention, if a node in partition #1 wants to issue a new transaction and generate block X, it needs to select a block in the ledger maintained by node #1 in partition as the tip of the partition main chain.

[0081] Based on the partition node main chain determination algorithm, the partition node in partition #1 can determine the tip of the partition after obtaining the main chain of the corresponding partition through the DAG master node DM1.

[0082] As shown in Figure 6, boxes represent blocks. In this example, each block's weight is set to 1, and the number within each box represents the cumulative weight. For example, if block E is directly or indirectly selected by blocks A, B, C, and D, E's cumulative weight is 5, which is the sum of E's own weight and the weights of A, B, C, and D. Using Algorithm 3, we can determine that the main chain of this partition is the main chain containing block A. Since block A is a tip, the newly generated block X will select block A as the tip block within the partition and use block A's hash value as block X's hashIntra value.

[0083] At the same time, the new Tip is updated to complete the Tip selection within the partition, and the hash value of the main chain Tip in the selected partition is used as the hashIntra of the new block.

[0084] At this point, in partition 1#, only block A is not selected, so block A is used as the Tip in partition 1#. The hash value of the Tip block A in the partition main chain that the new block X can select is used as hashIntra.

[0085] 2.3 Inter-partition Tip selection: Select the tip of the main chain of other partitions, hashInter is the hash of the tip.

[0086] In addition to selecting the Tip within the partition as the hashIntra of the new block, it is also necessary to select the Tip in the main chain of other partitions and use the hash value of the Tip as the hashInter in the new block.

[0087] As shown in Figure 1, in this example, in addition to partition #1, there are two more partitions. For the height of block X, a suitable key-value pair can be selected from Recently-Selected (i.e., historical key-value pairs) for hashInter in block X. Recently-Selceted has B as an optional key-value pair (9, (partition #3, Hash (block B))). Therefore, block B is selected as the Tip between partitions, and the hash value of block B is used as the hashInter in the new block X. The blocks generated later can be based on DM zoneInter The Markov Chain Monte Carlo (MCMC) algorithm result of the local DAG ledger selects hashInter pointing to the top of the partition #zoneInter main chain, thereby updating the key-value pair in Recent-Selected.

[0088] In the process of generating a new block, this embodiment uses the hash value of the generated block and the block at the end of the main chain in the blockchain it maintains as the hashIntra of the current block; the DAG node of the current partition selects a hash value of a block that has not been selected and generated for other consensus partitions from the DAG-based main chain ledger it maintains as the hashInte of the current block.

[0089] 2.4 Block Generation: Through the selected hashIntra and hashInter, blocks can be generated according to the consensus algorithm adopted by the partition.

[0090] According to the Tip selection algorithm, block A in the partition is selected as the hashIntra of the new block X, and block B in other partitions is selected as the hashInter of the new block X.

[0091] Different zones may run different consensus algorithms, and blocks are generated in Zone #1 based on the consensus algorithm used by the zone. To ensure that zones with fast block generation speeds do not dominate the entire architecture, the weight of a block is proportional to the amount of work done to generate the block within the zone.

[0092] The cumulative weight of a block is the sum of the weight of the block and the weights of the blocks that directly or indirectly validate the block.

[0093] In this example, chain node block verification involves verifying transactions and blocks, including transaction order, transaction signatures, and the number of transactions included. Block verification verifies whether the generated block complies with the blockchain rules of the partition, performing block size verification, block order verification, and other verifications. In this example, assuming that the PoW consensus algorithm is used in partition #1, it is necessary to verify whether the corresponding nonce value calculated during block generation meets the requirements. After block verification by chain nodes within partition #1, the verified block X will proceed to the next step, such as dissemination to nodes in other partitions and the DAG master node for further verification.

[0094] After a chain node block is verified, the ledger within the partition will be updated. Successfully published blocks will not be confirmed until their cumulative weight reaches a pre-set threshold. The cumulative weight calculation process is shown in Figure 7. After block X is generated and blocks A and B are selected, block X becomes the only Tip, and the cumulative weight of all other blocks increases by 1 (X's own weight).

[0095] In Figure 7, block X directly or indirectly selects blocks A, B, C, D, and E, so D's score is 1+1+1+1=4. Similarly, E's score is 1+1+1+1+1+1=6.

[0096] After a newly generated block X passes block verification within its partition, it must be propagated to the DAG master node for DAG block verification. The master node for blockchain #y is in partition #1, so CMs only need to run block verification for their own partitions. DM1, as the coordinator of the single chain in partition #1, must run DAG block verification. Based on the DAG master ledger, it verifies that the inter-partition block links are correct and that the main chain of the partition containing the newly generated block is the most heavily weighted main chain within the partition.

[0097] 2.5 DAG ledger update

[0098] After passing the DAG master node verification, the DAG node will update the ledger based on the intra-partition Tip and inter-partition Tip selected above, and update the main ledger.

[0099] The present invention proposes an innovative two-layer multi-partition blockchain architecture, in which the DAG master node and the partition node together constitute a two-layer partition blockchain system architecture. Under the two-layer multi-partition architecture, stable and personalized applications can be established in each partition to provide user privacy and data permission protection for each partition, while improving scalability and ensuring performance and security. In order to verify the design of the present invention, an actual system was implemented using C++, and experiments were run on 5 virtual machines, each with 10 cores and 16GB of memory. The chain nodes in each partition are evenly distributed on the 5 virtual machines, forming a ring virtual topology. A total of 1,000 chain nodes are run, and the chain nodes of each partition use the PoW consensus mechanism to generate blocks, and the longest chain rule (LCR) is used as the main chain determination strategy. Through difficulty adjustment, the block generation speed of each area is limited to an average of 10 minutes per block, where the difficulty is adjusted every 5 blocks. When the block generation rate in each area is roughly the same, we can let Q in Algorithm 2 i = 1, where i∈N. The performance and security of the present invention are evaluated. The security of the present invention is demonstrated through simulation experiments.

[0100] First, from the block generation difficulty analysis in the experiment, the larger the PoW targetHash, the easier it is to generate a block. In this experiment, targetHash is used to represent the degree of difficulty. This example calculates the average targetHash of blocks with the same height in all main chains. As shown in Figure 4, targetHash is independently adjusted every 5 blocks in each zone, which follows the settings in the difficulty adjustment. As the block height increases, the statistical average targetHash drops sharply when the block height is ≤30 and is relatively stable when the block height is >30. Generally speaking, after the height reaches 30, the larger the n, the higher the targetHash, which means that increasing n can reduce the energy consumption of block generation in multi-partition consensus. Since increasing n can reduce the competition for block generation within each partition, we can conclude that the multi-partition consensus mechanism will be able to reduce the resource consumption of other consensus algorithms during future expansion.

[0101] Using the statistics after block height 30, the orphan block generation rate is The effective block generation rate is

[0102] As can be seen from Figure 5, the effective block speed of the present invention increases linearly with the increase of n. A faster effective block speed means faster transaction encapsulation and processing, which makes the blockchain have better scalability. Based on the compatibility of the multi-partition consensus method and the single-chain consensus algorithm, it can be concluded that the multi-partition consensus mechanism can make the single-chain blockchain linearly scalable.

[0103] Similarly, only statistical data with a block height of 30 or more is used. As n increases, the running time of different fixed w decreases and eventually tends to be flat. The larger n is, the higher the effective block generation rate is. It can be concluded that the two-layer multi-shard consensus system proposed in this paper can increase the generation rate and improve system performance while reducing resource consumption.

[0104] 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 double-layer multi-partition blockchain system, characterized in that, The system includes multiple consensus partitions and a coordination layer. Each consensus partition includes multiple partition nodes and a DAG node. Each consensus partition maintains a blockchain. The partition nodes and DAG nodes in each consensus partition are intelligent terminals with computing and communication capabilities. The partition nodes participate in the competition for generating blocks in the blockchain of the consensus partition, and the DAG node does not participate in the generation of blocks in the partition blockchain. The DAG nodes of all partitions constitute the coordination layer. The DAG node forwards the blocks generated by the partition to the coordination layer. The coordination layer maintains a DAG-based main chain ledger, and the DAG ledger in DAG consensus is composed of blocks generated by all partitions.

2. The double-layer multi-partition blockchain system according to claim 1, characterized in that, Each consensus partition adopts a different consensus algorithm.

3. The double-layer multi-partition blockchain system according to claim 1, wherein The information types included in at least each block generated by a partition are expressed as: {height, zoneIntra, hashIntra, txIntra, zoneInter, hashInter, txInter} Among them, height is the block height of the distributed ledger maintained by the current consensus partition; zoneIntra represents the partition node that generates the current block; hashIntra represents the hash value of the block linked to the current block in the current consensus partition; txIntra represents the transaction input in the consensus partition zoneIntra and output in the consensus partition zoneIntra; zoneInter represents a consensus partition other than the one where the current block is located; hashInte represents the hash value of the block linked to the current block in the consensus partition zoneInter; txInter represents the transaction input in the consensus partition zoneIntra and output at the partition node zoneInter.

4. A two-layer multi-partition blockchain system according to claim 2, wherein In the consensus partition, when generating a block, the partition node uses the hash value of the block at the end of the main chain in the blockchain it maintains and the generated block as the hashIntra of the current block; the DAG node of the current partition selects, from the DAG-based main chain ledger it maintains, a hash value of a block that has not been selected and is generated for other consensus partitions as the hashInte of the current block.

5. A double-layer multi-partition blockchain system according to claim 1, 2 or 4, characterized in that, In the consensus partition, the new block searches for historical key-value pairs according to the height of the current block. If the historical key-value pair exists at this height, the parameters at this height are called for block generation. Otherwise, the Markov chain Monte Carlo algorithm is used to obtain parameters from the local ledger of the blockchain. A historical key-value pair is expressed as (height, {hashInter, zoneInter}), where height is the block height of the distributed ledger maintained by the current consensus partition, hashInte represents the hash value of the block linked to the current block in the consensus partition zoneInter, zoneInter represents a consensus partition other than the one where the current block is located, and there is only one historical key-value pair at the same height in the same partition.

6. The bilayer multi-partition blockchain system according to claim 5, wherein The process of using the Markov chain Monte Carlo algorithm to obtain hashInter and zoneInter from the local ledger of the blockchain includes: Select the block with a higher weight from each partition as the starting block, and place a particle on each block; Take the blocks that can be selected as the current block in other partitions as the destination blocks, and the blocks that can directly or indirectly prove the current block as the relay blocks, and let the particles on the starting block perform random walks; Take the partition where the particle that first reaches the destination block arrives as the zoneInter of the current block, and the hash value of the target block reached as the hashInter of the current block.

7. A two-layer multi-partition blockchain system according to claim 4, characterized in that, Update the partition main chain, that is, ensure that the block with the highest height and the largest cumulative weight in the current partition is on the same chain as the latest generated block in the current partition, and take this chain as the main chain of the partition.

Images