A Consortium Blockchain Data Query Method Based on Consensus Group Partitioning and Multi - layer Indexing

Abstract

The present invention designs a consortium chain data query method based on consensus group division and multi-layer indexing; aiming at the problems of poor indexing performance and poor scalability in multi-node scenarios in the consortium chain system, research on consortium chain query design is carried out to improve query performance and security; the fabric system is improved, and a node consensus group model is proposed; there are master and slave nodes in the consensus group and there are multiple layers. After the nodes reach consensus within the group, the consensus process is recursively repeated to finally reach a multi-layer PBFT consensus protocol; a two-layer skip list index model is proposed, where the upper layer is used to find the search range of the underlying layer containing the query status; the underlying layer is used to index and query the blockchain status; the positions in the top and bottom layers of the two-layer skip list are calculated through the newly generated block version number to construct the index; the top index position is calculated through the version number, the layer where the bottom skip list is located is calculated and searched to obtain the target data entry node, and the target block data is queried through the entry node and verified and returned to the client.

Description

Technical Field

[0001] The present invention relates to the field of blockchain query, and specifically relates to a method for querying consortium chain data based on consensus group division and multi-level indexing. Background Art

[0002] With the continuous development of today's society and the continuous progress of science and technology, many novel technologies have emerged. For example, 5G technology, chatGPT, artificial intelligence, AI, cloud technology, big data, and blockchain technologies. With the continuous in-depth research of these technologies by researchers, a large number of related technology products have been put into use. The initially applied underlying technology is blockchain technology. Blockchain achieves data security and trust by storing data in a series of linked blocks. Each block contains the hash value of the previous block, forming an immutable data chain. Blockchain technology has received continuous attention and research from domestic and foreign researchers due to its characteristics such as immutability, decentralization, and data transparency.

[0003] Blockchain technology combines a variety of other key technologies, such as distributed systems, cryptography, Merkle trees, and consensus algorithms. The essence of blockchain technology is a decentralized distributed database, but different from traditional centralized distributed databases, all data in the system is backed up by each node in the blockchain network, which can improve the query efficiency of nodes and ensure the data security of the system to a certain extent, and can also reduce the maintenance cost of the original database maintainer. Blockchain can be divided into public chains and private chains. A public chain is a blockchain network that everyone can participate in and access, and anyone can join and participate in the maintenance and transactions of the network. A private chain is a blockchain that is only used by specific people or organizations, and these people or organizations can maintain the network and control access rights by themselves.

[0004] For different types of blockchains, the consensus algorithms used to reach consensus are also different. The consensus algorithm sorts transactions and ensures the integrity and consistency of blockchain across geographically distributed nodes, which largely determines the performance of distributed systems, especially blockchains, such as transaction throughput, latency, node scalability, security level, etc., and is very important for blockchains. Different consensus algorithms can be considered according to application scenarios and performance requirements. The two most commonly used consensus algorithms in public blockchains are the PoW algorithm (Proof of Work) and the PoS algorithm (Proof of Stake). Among private blockchains, consortium blockchains are the most common. Participants usually have the right to audit and verify blockchain transactions, which makes consortium blockchains more efficient, scalable, and secure than public blockchains. In addition, consortium blockchains usually allow participants to have more refined control and management over transactions. For example, only specific participants are allowed to participate in certain transactions or only specific participants are allowed to access specific data. These features make consortium blockchains more advantageous in protecting privacy, protecting intellectual property rights, and ensuring compliance. Currently, a large number of consortium blockchain systems are based on full replication backups. As more nodes are continuously added to the system and more blocks are continuously written, the number of nodes in the system and the stored blockchain data are increasing, which will greatly affect the query performance of the blockchain. Therefore, the issues of multi-node processing and query performance optimization in consortium blockchains need to be solved urgently.

[0005] The aspects involved in optimizing the query performance of data in consortium blockchains are relatively broad. A relatively common approach is to store a small amount of metadata on the chain, while a large amount of raw data is stored in a database off the chain. Although this approach can improve the query efficiency of the system, there are significant security risks in its data security verification. Another example is to design data structures such as Bloom filters or B+ trees as indexes, but the query performance improvement for systems with large amounts of data is limited. Most index designs can only support one-dimensional data queries and cannot support multi-dimensional data queries. Moreover, most nodes in consortium blockchains reach consensus through a single layer of nodes. The time complexity of reaching consensus through a single layer of nodes is relatively high, and there is a bottleneck upper limit for the expansion of the number of nodes. The more nodes there are, the more it will affect the query performance of the system. Summary of the Invention

[0006] In view of the deficiencies of the prior art, the present invention designs a consortium blockchain data query method based on consensus group partitioning and multi-layer indexing.

[0007] A consortium blockchain data query method based on consensus group partitioning and multi-layer indexing specifically includes the following steps:

[0008] Step 1: Divide the nodes in fabric into an architecture of multiple consensus groups;

[0009] Divide the nodes in the consortium blockchain network into multiple consensus groups. Each consensus group contains multiple levels, where is the i-th node of the m-th layer, where the superscript m represents the layer number of the blockchain node, and the subscript i represents the index position of the node in the current layer; is a node of the m+1 layer is the leader node; Nodes in each consensus group meet the basic requirements of the PBFT Practical Byzantine Consensus Protocol, that is, the number of nodes num in the consensus group satisfies the inequality num >= 3f + 1, where f is the number of malicious nodes in the consensus group; And the leader node in the consensus group reaches a small consensus with the master node within the group, and iterates this process to the upper-layer nodes in turn; All nodes finally reach a multi-layer consensus. Compared with the single-layer node PBFT, it can reduce the consensus time complexity and support more nodes to join;

[0010] Step 2: The client node submits a transaction proposal to the endorser nodes of the fabric network. The transaction proposal sends the contract identifier, contract method, parameter information to be invoked in this transaction, and the client signature information to the endorser nodes;

[0011] Step 3: After receiving the transaction proposal, the endorser nodes verify the signature and determine whether the submitter has the right to execute the operation. At the same time, they simulate the execution of the smart contract according to the endorsement policy and send the results and their respective CA certificate signatures back to the application client;

[0012] Step 4: After receiving the information returned by the endorser nodes, the client determines whether the proposal results are consistent and whether they are executed according to the specified endorsement policy. If there are not enough endorsements, the process is aborted; Otherwise, the application client packs the data together to form a transaction, signs it, and sends it to the consensus group ordering node;

[0013] Step 5: The consensus group ordering node performs multi-layer PBFT consensus sorting on the received transactions, packs the transactions to generate a new block, and sends it to the commit node; After receiving the block, the commit node verifies the transactions in the block, and after completion, appends the block to the local blockchain and modifies the world state;

[0014] The world state is specifically represented as: Define a world state entry as a tuple (k, (va1, va2,..., van), ver), where k is the key of the blockchain state, (va1, va2,..., van) is a set of different types of values or a single value, ver is the version number of the world state. The insertion of each piece of data will cause a change in the world state, and the value of ver increases by 1 unit;

[0015] The key of the blockchain state is regarded as account u, and the relevant historical state record structure is as follows: pre represents the prefix, the prefix 01 represents the reputation value, 10 represents the balance value, pre_val is the prefix counter, indicating the number of previous blocks with the same prefix as the current block prefix. 1 means not modified, that is, there is 1 previous block with the same prefix as this block; 0 means modified, that is, there are 0 previous blocks with the same prefix as this block; (Txn, Block) indicates which transaction modified which block; Statevalue represents the multi-dimensional state value set; Version represents the version number of the block. The corresponding counter of the prefix is reserved to calculate whether the committed transaction has changed this specific value; in state S k2,v2 Under, the transaction txn1 in block b updates two balances and reputation values (B, R), so the prefix values of these two values are both 0; in the next state S k2,v3 In, the transaction txn2 updates the balance but does not change the reputation. Therefore, the value of the prefix 01 increases by 1, indicating that the reputation has the same value state S k2,v3 And the previous state; k2,v2 ; on the other hand, the prefix 10 is 0 in this state S k2,v3 , indicating that the balance is updated from the previous state S k2,v2 By the transaction txn2 in block b + 1;

[0016] Step 6: Construct a two-layer skip list index for the newly generated block;

[0017] When designing the two-layer skip list, the latest state is appended to its previous state; the two-layer skip list has two layers of indexes: the first layer is used to find the search range of the underlying skip list containing the query state; the second layer is correspondingly improved based on the skip list to index and query the blockchain state; the nodes in the second-layer skip list are composed of the reputation prefix value, balance, and version number respectively; the skip list consists of multiple levels of linked lists, and a node belongs to multiple levels; the two-layer skip list has n layers in the second-layer skip list; therefore, it has n entries in the first layer; for the first entry, assign i = 0, j = 1, and the node of the first entry is (2 i , 2 j ) = (1, 2). In the second entry, increase the values of i and j by 1. Therefore, the node of the second entry is (2 i , 2 j ) = (2, 4); similarly, select the state version for the next entry; but for the last entry, since the node has not been created yet, it points to the latest node, and this entry will be updated until the entry node with version number 2 n Is generated; each layer of the skip list has a different skip interval to select nodes; the skip interval of the nth level L n Is d n, the value of d is 2; taking the third layer as an example, the jump distance is 2 3 = 8, and the nodes selected from the current layer list are {8, 16};

[0018] As the number of transactions in the consortium chain increases, the number of blocks in the consortium chain system also increases, and it is necessary to build a new index on top of the original index structure; after a new block is generated, the transaction version number ver in the block is used as the input to build an index in the double-layer skip list; the steps are as follows:

[0019] Step 6.1: Use the transaction version number ver of the new block as the input of the double-layer skip list, and calculate the top-level index version number ver through the formula top_tier ;

[0020] Step 6.2: Judge whether ver top_tier belongs to the top-level index interval set of the double-layer skip list; if so, go to Step 6.3, otherwise go to Step 6.4;

[0021] Step 6.3: Update the latest data entry at the top layer with the version number ver as the second node; traverse i from 0 to the top-level version number ver top_tier , if the remainder of the version number ver divided by 2 i is 0, it means that the version number ver is the endpoint of a certain interval at the top layer, then add the version number ver to the interval endpoint set and end;

[0022] Step 6.4: Create a new entry, use the version ver as the first node in the top layer, and traverse the variable i from 0 to the top-level version number ver top_tier , if the remainder of the version number ver divided by 2 i is 0, it means that the version number ver is the endpoint of a certain interval at the top layer, then add the version number ver to the interval endpoint set and end;

[0023] Step 7: The client sends a query request to the peer node in the consensus group. After receiving the query request, the peer node queries based on the index in Step 6 and verifies the block data;

[0024] Step 7.1: Calculate the index number I where the data entry with the version number ver is located at the top layer of the skip list through the calculation formula ;

[0025] Step 7.2: Obtain the range of the bottom-layer skip list nodes that can be indexed by the data entry with the version number ver at the top layer through the index number I [2 I , 2 I+1 ;

[0026] Step 7.3: According to the node range in Step 7.2 and the maximum node distance calculation formula d = 2​I+1 -ver obtains the distance d between the target data entry node and the right-end node of the interval in the underlying skip list;

[0027] Step 7.4: Calculate the layer number L of the target data entry node in the underlying skip list through the nearest node distance d calculated in Step 7.3 and the formula ;

[0028] Step 7.5: Start searching from the node with version number 2 at the right end of the interval on the skip list with layer number L. If the version number of the data entry is ver, the target data entry is found; otherwise, the query fails and the process ends; I+1 ;

[0029] Step 7.6: Index the block containing the target world state in the consortium chain according to the version number ver of the found data entry node;

[0030] Step 7.7: Perform security verification on the block data. If they are consistent, return them to the client node; otherwise, the search fails and the process ends.

[0031] Advantageous technical effects of the present invention:

[0032] Compared with the single-layer PBFT consensus of nodes, the multi-layer PBFT consensus of the consensus group can reduce the time complexity of reaching a consensus; compared with the use of a single-layer skip list, the double-layer skip list can index the target data block faster; compared with some other indexes, the double-layer skip list can increase the query of multi-dimensional historical state data;

[0033] Based on the technical advantages such as permission entry of the consortium chain and using a trusted execution environment to improve the internal organization of Fabric and the internal data structure of nodes as the basis for query optimization; it greatly improves the security of blockchain technology, especially in the trusted environment of consortium chain nodes. Based on weakening the concept of the internal organization of the consortium chain, it realizes more efficient data security query. Most of the existing blockchain indexes can only support the query of one-dimensional historical state data, and the present invention can increase the query of multi-dimensional historical state data; compared with the single-layer skip list index, the present invention can index the target block data faster. Description of the Drawings

[0034] Figure 1 is the architecture diagram of a method for querying consortium chain data based on consensus group division and multi-layer index of the present invention;

[0035] Figure 2 is the model diagram of node division consensus group of the present invention;

[0036] Figure 3 is the structure diagram of historical state data of the present invention;

[0037] Figure 4This is the diagram of the double - layer skip list index model of the present invention;

[0038] Figure 5 This is the flow chart for constructing the double - layer skip list index of the present invention;

[0039] Figure 6 This is the data query flow chart based on the double - layer skip list of the present invention. Detailed implementation manners

[0040] The following further describes the present invention in conjunction with the drawings and embodiments;

[0041] Based on the technical advantages such as permissioned access of the consortium blockchain and based on the trusted execution environment, the present invention improves the internal organizations of Fabric and the internal data structures of nodes, and serves as the basis for query optimization. Currently, popular research points include SGX and enhanced SGX hardware protection technology, which greatly improve the security of blockchain technology, especially in the trusted environment of consortium blockchain nodes. Therefore, based on the concept of weakening the internal organizations of the consortium blockchain, a more efficient data security query method is realized.

[0042] A method for querying consortium blockchain data based on consensus group division and multi - layer indexing, as shown in the appendix Figure 1 is shown, and specifically includes the following steps:

[0043] Step 1: Divide the nodes in fabric into an architecture of multiple consensus groups;

[0044] The consortium blockchain system has the characteristic of decentralization, where each node has the same status, and nodes in the consortium blockchain system communicate and exchange data. As more and more nodes join the consortium blockchain network, the network is filled with a large number of nodes. Without proper handling, it will undoubtedly reduce the throughput of the consortium blockchain system and affect the query performance of the system. Therefore, the present invention innovatively proposes a consortium blockchain node group architecture based on node grouping for this situation.

[0045] As Figure 2 shown, the present invention divides the nodes in the consortium blockchain network into multiple consensus groups. Each consensus group contains multiple levels, where is the i - th node in the m - th layer. The superscript m represents the layer number where the blockchain node is located, and the subscript i represents the index position of the node in the corresponding layer; is the node in the m + 1 layer The leader nodes; the nodes in each consensus group meet the basic requirements of the PBFT Practical Byzantine Consensus Protocol, that is, the number of nodes num in the consensus group satisfies the inequality num >= 3f + 1, where f is the number of malicious nodes in the consensus group; and the leader nodes in the consensus group reach a small consensus within the group with the master node, and iterate this process up to the upper-layer nodes in turn; all nodes finally reach a multi-layer consensus. There are a total of 1 + m * (m + n) nodes in the network, and the communication complexity of the multi-layer PBFT consensus group system is analyzed and compared. The security analysis shows that the security performance of the consensus algorithm continuously improves over time and can accommodate at most faulty nodes, ensuring the absolute security of the system under malicious attacks. At the same time, compared with the traditional single-layer PBFT network consensus, the multi-layer PBFT consensus only requires m * (m + n) inter-node messages, rather than O((m + n) 2 *m 2 ) messages, thereby reducing the time required for system consensus.

[0046] Step 2: The client node submits a transaction proposal to the endorser nodes of the fabric network. The transaction proposal sends the contract identifier, contract method and parameter information to be invoked in this transaction, as well as the client signature information to the endorser nodes.

[0047] Step 3: After receiving the transaction proposal, the endorser nodes verify the signature and determine whether the submitter has the right to execute the operation. At the same time, they simulate the execution of the smart contract according to the endorsement policy and send the results and their respective CA certificate signatures back to the application client;

[0048] Step 4: After the client receives the information returned by the endorser nodes, it judges whether the proposal results are consistent and whether they are executed according to the specified endorsement policy. If there are not enough endorsements, the processing is aborted; otherwise, the application client packs the data together to form a transaction, signs it, and sends it to the consensus group ordering nodes;

[0049] Step 5: The consensus group ordering nodes perform multi-layer PBFT consensus sorting on the received transactions, pack the transactions to generate a new block, and send it to the commit node; after receiving the block, the commit node verifies the transactions in the block, and after completion, appends the block to the local blockchain and modifies the world state;

[0050] The present invention defines a world state entry as a tuple (k, (va1, va2,..., van), ver), where k is the key of the blockchain state, (va1, va2,..., van) is a set of different types of values or can be a single value, and ver is the version number of the world state. The insertion of each piece of data will cause a change in the world state, and the value of ver increases by 1 unit in size.

[0051] The structure diagram of the historical status records related to account u is as Figure 3 shown. pre represents the prefix. The prefix 01 represents the credit value, and 10 represents the balance value. pre_val is the prefix counter, indicating the number of previous blocks with the same prefix as the current block. 1 means not modified, that is, there is 1 previous block with the same prefix as this block; 0 means modified, that is, there are 0 previous blocks with the same prefix as this block; (Txn, Block) indicates which transaction modified which block; State value represents the multi-dimensional state value set; Version represents the version number of the block. In addition, the present invention retains the corresponding counter of the prefix for calculating whether the submitted transaction changes the specific value. From Figure 3 it can be seen that in state S k2,v2 , the transaction txn1 in block b updated two values (B, R), so the prefix values in both cases are 0. In the next state S k2,v3 , the transaction txn2 updated the balance but did not change the credit. Therefore, the value of the prefix 01 increased by 1, indicating that the credit has the same value state in the current state S k2,v3 and the previous state S k2,v2 . On the other hand, the prefix 10 is 0 in this state S k2,v3 , indicating that the balance was updated by the transaction txn2 in block b + 1 from the previous state S k2,v2 .

[0052] Step 6: Construct a two-layer skip list index for the newly generated block;

[0053] Some related applications in the blockchain generate data very frequently, and the methods for processing hot and cold data in previous research work are quite extensive. As the number of transaction transactions in the consortium blockchain system increases, the amount of data on the blockchain increases more significantly. Therefore, in the face of the exponentially growing amount of data, whether the data is "cold" or "hot", an appropriate index model must be designed to handle this. Since these data structures can effectively update the index for the frequently generated data, this method can work well.

[0054] In view of these problems, the present invention innovatively proposes an index model based on a two-layer skip list. When designing the two-layer skip list, the present invention attaches the latest state to its previous state. As Figure 4 shown, the two-layer skip list has two layers of indexes: (i) The first layer is used to find the search range of the underlying skip list containing the query state; (ii) The second layer is correspondingly improved based on the skip list to index and query the blockchain state; The nodes in the second-layer skip list are respectively composed of the credit prefix value, balance, and version number; The skip list is composed of multiple levels of linked lists, and a node may belong to multiple levels; From Figure 4It can be seen in [description] that there are five levels in the second-level skip list of the double-layer skip list; therefore, it has five entries in the first level; for the first entry, assign i = 0 and j = 1, and the node of the first entry is (2 i ,2 j ) = (1, 2),... In the second entry, increase the values of i and j by 1, so the node of the second entry is (2 i ,2 j ) = (2, 4); similarly, select the state version for the next entry; but for the last entry, since node 32 has not been created yet, it points to the latest node, and this table entry will be updated until 32 is generated; each level of the skip list has a different skip interval to select nodes; the skip interval of the nth level L n is d n , and the value of d is 2; taking the third level as an example, the skip distance is 2 3 = 8, and the nodes selected from the current layer list are {8, 16};

[0055] As the number of transactions in the consortium chain increases, the number of blocks in the consortium chain system also increases, and it is necessary to build a new index on top of the original index structure; after a new block is generated, use the transaction version number ver in the block as the input to build an index in the double-layer skip list; as shown in the appendix Figure 5 as follows:

[0056] Step 6.1: Use the transaction version number ver of the new block as the input of the double-layer skip list, and calculate the top-level index version number ver through the formula ; top_tier ;

[0057] Step 6.2: Determine whether ver top_tier belongs to the top-level index interval set of the double-layer skip list; if yes, go to Step 6.3, otherwise go to Step 6.4;

[0058] Step 6.3: Update the latest data entry at the top layer with the version number ver as the second node; traverse i from 0 to the top-level version number ver top_tier , if the remainder of the version number ver divided by 2 i is 0, it means that the version number ver is an endpoint of a certain interval at the top layer, then add the version number ver to the interval endpoint set and end;

[0059] Step 6.4: Create a new entry, use the version ver as the first node in the top layer, and traverse the variable i from 0 to the top-level version number ver top_tier , if the remainder of the version number ver divided by 2 i is 0, it means that the version number ver is an endpoint of a certain interval at the top layer, then add the version number ver to the interval endpoint set and end;

[0060] Step 7: The client sends a query request to the peer nodes in the consensus group. After receiving the query request, the peer nodes query and verify the data based on the multi-layer index structure;

[0061] An index is a data structure used to accelerate database queries. It can improve the efficiency of queries and reduce the cost of queries. An index can be regarded as a pointer to a specific column in a database table. This pointer can help the database quickly locate the data rows that need to be queried, thus avoiding the operation of full table scans. When the amount of data in a database table is very large, without an index, the query operation needs to traverse the entire table. Such an operation will greatly reduce the query efficiency and may cause bottlenecks in the system. With an index, the database can quickly locate the data rows that need to be queried using the index without having to scan the entire table, so the query speed will be greatly improved. However, existing research shows that the index query performance designed by current researchers is poor, and many designed index structures can only support one-dimensional key-value pair data queries with hash values as keywords and cannot support multi-dimensional data queries. For example, there are many other attribute value data in the supermarket accounts, such as points and balances. Using the above index obviously cannot meet the application requirements.

[0062] To address this problem, the present invention implements a data query method based on a double-layer skip list. Compared with using only a skip list to implement index queries, the double-layer skip list can index to the bottom skip list faster through the underlying index number, thus avoiding traversing and querying from each layer of the skip list and reducing the query time. This method can calculate the first-layer index number and the range of node intervals where a certain data entry is located based on the version number of the data entry, and then obtain the second-layer index layer number through relevant calculations. Starting from the right-end node of the interval, search and query to the target data entry, and query the block data containing the target world state at the bottom layer of the consortium chain according to the target data entry node as the index. Based on the double-layer skip list index structure, according to Figure 6 The data query process schematic diagram describes the specific query process of the version number ver of a certain data entry. The steps are as follows:

[0063] Step 7.1: Calculate the index number I at the top layer of the skip list where the data entry with version number ver is located through the calculation formula ;

[0064] Step 7.2: Obtain the range of nodes in the bottom skip list that the data entry with version number ver can index at the top layer through the index number I [2 I , 2 I+1 ;

[0065] Step 7.3: Through the node range in Step 7.2 and the maximum node distance calculation formula d = 2 I+1-ver obtains the distance d between the target data entry node and the right - hand node of the interval in the underlying skip list;

[0066] Step 7.4: Calculate the layer number L of the target data entry node in the underlying skip list by using the nearest node distance d calculated in Step 7.3 and the formula Calculate the layer number L of the target data entry node in the underlying skip list;

[0067] Step 7.5: Start searching from the node with version number 2 at the right - hand end of the interval on the skip list with layer number L. If the version number of the data entry is ver, the target data entry is found; otherwise, the query fails and the process ends; I+1 Start searching from the node with version number 2 at the right - hand end of the interval on the skip list with layer number L. If the version number of the data entry is ver, the target data entry is found; otherwise, the query fails and the process ends;

[0068] Step 7.6: Index the block containing the target world state in the consortium chain according to the version number ver of the found data entry node;

[0069] Step 7.7: Perform security verification on the block data. If they are consistent, return to the client node; otherwise, the search fails and the process ends.

[0070] The indicators to be achieved by the present invention are as follows:

[0071] Decentralized feature. By referring to relevant literature and materials, it is known that in data queries in traditional centralized distributed databases, many are based on a centralized organization for querying. This does not conform to the decentralized feature of the blockchain. Therefore, ensuring the decentralized feature of the blockchain system is a necessary condition.

[0072] Data security verification. There may be malicious nodes tampering with data, resulting in the target data found not being the desired data. Therefore, if we want to ensure the consistency between the found data and the data stored at the blockchain bottom layer, data verification is required.

[0073] The storage space occupied by the index is as small as possible. As is well known, the storage space of blockchain nodes is limited. If the index structure is designed too complexly, it will undoubtedly increase the storage resource consumption of the nodes and bring a storage burden to the nodes. Therefore, it is necessary to consider the balance between space and time factors and design an index structure with better performance.

[0074] Based on the in-depth study of the relationship between blockchain storage and query and the consensus algorithm, the present invention innovatively proposes a multi-layer index design method for efficient data query and a node grouping method for expanding the number of nodes. This includes a two-layer skip list index design method to achieve efficient query of the data stored on the chain and multi-dimensional attribute value query; a data verification mechanism to ensure the authenticity and security of the target data queried on the chain; a multi-level PBFT Byzantine method for nodes to reduce the time complexity of reaching consensus in the consortium blockchain system; a system security design to handle unexpected situations of consortium blockchain nodes and preventive measures in advance; and a query interface layer design to ensure the decentralized characteristics of the system and make the queried data independent of a certain centralized node or organization. The present invention divides the nodes in the consortium blockchain network into multiple consensus groups, and each node in the consensus group is designed with a two-layer skip list data structure as the index used for query to achieve the innovative indicators of the present invention.

[0075] With the addition of nodes in the consortium blockchain network, the number of nodes in the network will become larger and larger. If nodes do not exit or the exit speed is slow, the entire network will show a bloated state, and it will take more time for the system to reach consensus, thus affecting the throughput rate of the system. Moreover, the single-layer consensus of nodes cannot be extended to a majority of nodes. In response to this situation, based on the Fabric consortium blockchain system, the present invention makes corresponding changes to its internal system structure and node internal based on the permissioned addition characteristics of the consortium blockchain and the Fabric trusted execution environment, so as to ensure the decentralized characteristics of the consortium blockchain.

[0076] The present invention mainly and innovatively proposes a method for dividing nodes in the consortium blockchain system into consensus groups, and constructing a two-layer skip list inside the nodes as an index and query method.

[0077] 1. Consortium blockchain node group architecture based on node grouping.

[0078] Although PBFT exhibits good performance in terms of latency, resource requirements, and node complexity, node scalability is a bottleneck for PBFT. Node scalability is a metric that measures how well the network can reflect the system's ability to handle an increasing number of nodes because it relies on a large amount of inter-node communication. Therefore, from the perspective of communication complexity, it is difficult for PBFT-based blockchains to scale to multiple nodes, unable to meet the scenario where consortium chain nodes cannot exit in a timely manner, thus affecting the system's metrics. Existing research has proposed consensus based on variant PBFT to address the problem of poor scalability. For example, PBFT with short-term signatures minimizes the consensus time for signature verification. Another important evolutionary path is sharding, where shards have their own consensus groups; thus, due to the smaller network size, transactions can be confirmed in a short time. However, the trade-offs include increased communication costs and reduced security levels. For example, each shard retains its own data and does not share it with other shards. In the case where a user requests contracts on multiple shards, inter-node communication will increase rapidly.

[0079] To address the above problems, the present invention designs a consortium chain multi-node consensus group partitioning architecture. First, all nodes in the consortium chain network are divided into multiple consensus groups, and the nodes in each consensus group meet the basic requirements of PBFT (Practical Byzantine Fault Tolerance). This design also stems from considerations of system security. If the number of nodes in the consensus group does not meet the inequality requirements mentioned above, there may be multiple malicious nodes in the consensus group, resulting in the modification of block data in the nodes and thus causing data query security problems.

[0080] 2. Index model based on a two-layer skip list;

[0081] The fields in which blockchain systems are applied are relatively extensive, especially in the financial industry. For example, in the banking system, users often need to view their historical transaction data. In such cases, an efficient and effective indexing method is required to quickly search and find specific data in the blockchain ledger. However, in order to effectively query data in the blockchain, many researchers have tried to establish indexing methods for blockchain systems. Unfortunately, existing methods can only query one-dimensional values, while the data stored in the blockchain is usually multi-dimensional.

[0082] In view of the above-mentioned problems, the present invention innovatively proposes a two-layer skip list as an index structure to support the query of multi-dimensional historical state data in the consortium blockchain. The skip list is used to index the multi-dimensional historical data versions, and the historical data is retrieved at the top layer, so as to achieve efficient query of multi-dimensional data. In fact, the historical records of the multi-dimensional blockchain state are generated by the blockchain transaction order. In order to distinguish and track the dimensions of the blockchain state, the present invention uses a prefix field. More specifically, the present invention constructs an index method using the multi-dimensional blockchain state and the prefix value, so as to perform the query operation of the blockchain historical data using the index model.

[0083] 3. Two-layer skip list index construction method;

[0084] The construction of the blockchain index is based on the generation of blocks. In the blockchain, the storage method of one-dimensional data is usually to record the data in a block, and then link this block with the previous block to form a continuously growing chain. The data in each block can be any type of data, including numbers, texts, pictures, etc. Since each block contains a pointer to the previous block, each block in the entire chain can be traced back to the genesis block. However, the blockchain can not only store simple key-value type data, but also store data types with multiple value values using ky as the key identifier. For each transaction generated in the blockchain, an index needs to be constructed in the two-layer skip list.

[0085] 4. Data query method based on two-layer skip list;

[0086] Some applications in the blockchain generate data at a high frequency. Therefore, an index model must be used to handle this function. For this purpose, this method can work well because it can effectively update its index using the frequently generated data. The two-layer skip list can quickly update its index by appending the state version to the skip list.

Claims

1. A consortium chain data query method based on consensus group division and multi-level indexing, characterized in that The specific steps include: Step 1: Divide the nodes in the fabric into multiple consensus groups; Step 2: The client node submits a transaction proposal to the endorsement node of the fabric network. The transaction proposal sends the contract identifier, contract method and parameter information to be called by this transaction, as well as the client signature information to the endorsement node; Step 3: After receiving the transaction proposal, the endorsing node verifies the signature and determines whether the submitter has the right to perform the operation. It also simulates the execution of the smart contract according to the endorsement policy and returns the result and its respective CA certificate signature to the application client. Step 4: After receiving the information returned by the endorsement node, the client determines whether the proposal result is consistent and whether it is executed according to the specified endorsement policy. If there is not enough endorsement, the processing is terminated; otherwise, the application client packages the data together into a transaction and signs it, and sends it to the consensus group sorting node; Step 5: The consensus group sorting node performs multi-layer PBFT consensus sorting on the received transactions and packages the transactions into a new block, which is then sent to the committing node; After receiving the block, the submitting node verifies the transactions in the block. After completion, it appends the block to the local blockchain and modifies the world state. Step 6: Build a double-layer skip list index for the newly generated block; Step 7: The client sends a query request to the peer node in the consensus group. After receiving the query request, the peer node queries and verifies the block data based on the index in step 6; Among them, step 6 designs a double-layer skip list by appending the latest state to its previous state; the double-layer skip list has two layers of indexes: the first layer is used to find the search range of the bottom-level skip list containing the query state; the second layer is improved accordingly based on the skip list to index and query the blockchain state; As the number of alliance chain transactions increases, the number of blocks in the alliance chain system also increases, and it is necessary to build a new index based on the original index structure; after the new block is generated, the transaction version number ver in the block is used as input to build an index in the double-layer jump list.

2. The method for querying consortium chain data based on consensus group division and multi - layer index according to claim 1, wherein Step 1 is as follows: The nodes in the consortium blockchain network are divided into multiple consensus groups, and each consensus group contains multiple levels. Among them is the i-th node in the m-th layer, where the superscript m represents the layer number where the blockchain node is located, and the subscript i represents the index position of the node in the corresponding layer; is the node in the (m + 1)-th layer and its leader node; the nodes in each consensus group all meet the basic requirements of the PBFT practical Byzantine consensus protocol, that is, the number of nodes num in the consensus group satisfies the inequality num >= 3f + 1, where f is the number of malicious nodes in the consensus group; and the leader node in the consensus group reaches a small consensus within the group with the master node, and iterates this process to the upper-level nodes in turn; all nodes finally reach a multi-level consensus. Compared with the single-layer node PBFT, it can reduce the consensus time complexity and support more nodes to join.

3. The method for querying consortium chain data based on consensus group division and multi-level index according to claim 1, characterized in that The world state described in step 5 is specifically expressed as follows: define the tuple (k, (va1, va2, ..., van), ver) as a world state entry, where k is the key of the blockchain state, (va1, va2, ..., van) is a collection of values of different types and also a single value, ver is the version number of the world state, and the insertion of each piece of data will cause a change in the world state, and the value of ver increases by 1 unit; The key of the blockchain state is regarded as account u, and the relevant historical state record structure is as follows: pre represents the prefix, the prefix 01 represents the reputation value, 10 represents the balance value, pre_val is the prefix counter, indicating the number of previous blocks with the same prefix as the current block. 1 means not modified, that is, there is 1 previous block with the same prefix as this block; 0 means modified, that is, there are 0 previous blocks with the same prefix as this block; (Txn, Block) indicates which transaction modified which block; State value represents the multi-dimensional state value set; Version represents the version number of the block; retain the corresponding counter for the prefix to calculate whether the committed transaction has changed this specific value; in state S k2,v2 under, the transaction txn1 in block b updated two balance and reputation values (B, R), so the prefix values of these two values are both 0; in the next state S k2,v3 in, the transaction txn2 updated the balance but did not change the reputation. Therefore, the value of the prefix 01 increased by 1, indicating that the reputation has the same value state S k2,v3 and the previous state; k2,v2 On the other hand, the prefix 10 is 0 in this state S k2,v3 indicating that the balance was updated by the transaction txn2 in block b + 1 from the previous state S k2,v2 .

4. A method for querying consortium chain data based on consensus group division and multi-level indexing according to claim 1, characterized in that The nodes in the second - level skip list are respectively composed of a reputation prefix value, a balance, and a version number; the skip list consists of multiple levels of linked lists, and a node belongs to multiple levels; the double - layer skip list has n layers in the second - level skip list; thus, it has n entries in the first level; for the first entry, when assigning i = 0, j = 1, the node of the first entry is (2 i ,2 j )=(1,2). In the second entry, the values of i and j are incremented by 1. Therefore, the node of the second entry is (2 i ,2 j )=(2,4); similarly, the status version is selected for the next entry; but for the last entry, since the node has not been created yet, it points to the latest node, and this entry will be updated until the entry node with version number 2 n is generated; each layer of the skip list has a different skip interval for selecting nodes; the skip interval of the nth level L n is d n , and the value of d is 2; taking the third layer as an example, the skip distance is 2 3 =8, and the nodes selected from the current - layer list are {8,16}.

5. The method for querying consortium chain data based on consensus group division and multi-level index according to claim 1, wherein Step 6: After the new block is generated, the transaction version number ver in the block is used as input to build an index in the double-layer jump list; the steps are: Step 6.1: Use the transaction version number ver of the new block as the input of the double-layer skip list, and calculate the top-level index version number ver through the formula ; top_tier ; Step 6.2: Determine whether ver top_tier belongs to the top index interval set of the double jump list; if yes, go to Step 6.3, otherwise go to Step 6.4; Step 6.3: Update the latest data entry at the top layer with the version number ver as the second node; from 0 to the top layer version number ver top_tier Traverse i. If the remainder of the version number ver divided by 2 i is 0, it indicates that the version number ver is an endpoint of a certain interval at the top layer, then add the version number ver to the set of interval endpoints and end; Step 6.4: Create a new entry, take version ver as the first node in the top layer, and traverse variable i from 0 to the top layer version number ver top_tier If the remainder of the version number ver divided by 2 i is 0, it indicates that the version number ver is an endpoint of a certain interval in the top layer. Then add the version number ver to the interval endpoint set and end.

6. The method for querying consortium chain data based on consensus group division and multi-layer index according to claim 1, characterized in that Step 7 is as follows: Step 7.1: Through the calculation formula calculate the index number I where the data entry with the version number ver is located at the top layer of the skip list; Step 7.2: Obtain the range of skip list nodes at the bottom layer that can be indexed by the top layer for the data entry with version number ver through index number I [2 I , 2 I+1 ; Step 7.3: Obtain the distance d between the target data entry node and the right-end node of the interval in the underlying skip list through the node range in Step 7.2 and the maximum node distance calculation formula d = 2 I+1 -ver; Step 7.4: Calculate the lowest-hop surface layer number L of the target data entry node with the nearest node distance d calculated in Step 7.3 and the formula ​ Step 7.5: Start a search from the node with version number 2 at the right end of the interval on the skip list with layer number L I+1 If the version number of the data entry is ver, the target data entry is found; otherwise, the query fails and the process ends. Step 7.6: Based on the version number ver of the found data entry node, the block containing the target world state is indexed in the alliance chain; Step 7.7: Perform security verification on the block data. If they are consistent, return them to the client node. Otherwise, the search fails. The process ends.

Images