Alliance chain ledger expansion storage method based on state data collaboration

Abstract

The present invention relates to the field of big data information security technology, and in particular to a state data collaborative alliance chain ledger dynamic expansion storage method, which divides the alliance chain world state database into different business world state databases according to different business scenarios, and the business world state database in each business domain is generated by the same business chain code; the consistency of the business world state data stored by the business node in the same business scenario is verified through the check side chain in the main side chain cross-anchor structure, and a hierarchical B+ tree corresponding to the business world state database of the business node is constructed, and the hierarchical nodes in the hierarchical B+ tree are used to divide the data in the business world state database into hot world state data stored by the business node and cold world state data stored by the storage device under the business domain chain. The present invention can realize the collaborative storage of state data by business nodes under the premise of mutual isolation of account book data between business domains, which is convenient for deployment and implementation in the business scenario of secure storage of account book data.

Description

Technical Field

[0001] The present invention relates to the field of big data information security technology, and in particular to a state data collaborative alliance chain account book dynamic expansion storage method. Background Art

[0002] Blockchain technology ensures high redundancy of ledger data by distributing globally consistent blockchain ledger data in multiple different nodes, avoiding single point failure problems caused by the damage of ledger data stored in individual nodes. While redundant storage of ledger data increases the security of blockchain systems, it also increases the ledger storage pressure of blockchain nodes. The large scale and rapid growth of blockchain ledgers have brought about serious blockchain storage scalability problems, which have become a bottleneck restricting the application of blockchain technology. Consortium chains strictly control access to ledger data and have a faster throughput rate than public chains, which can quickly reach consensus and upload blockchain transactions. At present, consortium chain technology has been widely used in actual business scenarios such as data circulation and sharing, data confirmation, and data traceability. However, due to the massive, heterogeneous and frequent chain-up requirements of various business data in actual business scenarios, consortium chains also face serious storage scalability problems.

[0003] At present, the research on blockchain storage scalability focuses on processing blocks in chained ledgers, ignoring the important role of state databases in blockchain ledger data. Consortium chains contain different types of ledger data. Chained ledgers ensure the security of block data by connecting end to end, but chained ledger data is stored in the form of files. Direct access to blockchain transactions in chained ledgers requires searching block files one by one, which is inefficient. The world state database is an extraction of key data in chained ledgers, and stores the latest value of the world state in the form of (key, value) key-value pairs. Compared with chained ledgers, the world state database has the characteristics of high value, small storage space, high query efficiency, and more fine-grained sharding. The world state database occupies an important position in the consortium chain system. In practical applications, retrieving the required ledger data from the world state database can meet most of the application requirements of the consortium chain system. At the same time, in existing application scenarios, consortium chain systems often have the need to process blockchain transactions in multiple business scenarios at the same time. The ledger data in different business scenarios needs to be isolated to ensure controllable access to the ledger data in different businesses and enhance the security of the ledger data. The consortium chain open source platform Hyperledger Fabric uses channel technology to process different business scenarios. Each business scenario processes and records its own ledger data through a separate channel. However, when constructing different channel chains, additional storage of channel configuration files is required. Organizations that join multiple channels need to store the ledger data of multiple channels in the accounting node, which increases the pressure on the accounting node to store the ledger data. Summary of the invention

[0004] To this end, the present invention provides a dynamic expansion storage method for alliance chain ledgers based on state data collaboration, which solves the problem of excessive pressure on alliance chain nodes in ledger storage in a big data environment and isolation between ledger data for different business scenarios. At the same time, the world state data is dynamically expanded and stored according to the update frequency, realizing collaborative storage of state data by business nodes under the premise of mutual isolation of ledger data between business domains.

[0005] According to the design scheme provided by the present invention, a method for dynamically expanding storage of alliance chain accounts based on state data collaboration is provided, comprising:

[0006] The alliance chain world state database is divided into different business world state databases according to different business scenarios. Each business node in the alliance chain stores the business world state database in its own business domain and checks the side chain block header. The business world state database in each business domain is generated by the same business chain code.

[0007] The consistency of the business world state data stored by the business nodes in the same business scenario is verified through the check side chain in the main-side chain cross-anchor structure, and a hierarchical B+ tree of the business world state database corresponding to the business node is constructed. The hierarchical nodes in the hierarchical B+ tree are used to divide the data in the business world state database into hot world state data stored by the business nodes and cold world state data stored by the storage devices under the business domain chain.

[0008] As a dynamic expansion storage method of alliance chain ledger based on state data collaboration of the present invention, further, for the business world state database, a state data collaborative storage architecture is used to collaboratively store and update the corresponding business world state data of business nodes in different business scenarios, wherein the alliance chain organization participants are divided into organization managers and business departments in the state data collaborative storage architecture, and the organization manager is used to build a master node for storing a complete alliance chain ledger in the corresponding business organization and manage all business departments within the business organization, and each business node is built through the business department. The master node of each business organization constitutes a master node domain, and the business nodes in the same organization are responsible for different businesses respectively and constitute a business domain with the business nodes responsible for the same business in other business organizations, and the business nodes are set to only receive business block data related to their own business, and the business nodes are used to verify the authenticity of the blockchain transactions in the business block, and the business world state database stored in itself is updated through the blockchain transactions in the business block.

[0009] As a dynamic expansion storage method of alliance chain ledger based on state data collaboration of the present invention, further, a business node is set to only receive business block data related to its own business, and a complete block is generated by using the alliance chain sorting service, and the blockchain transactions in the complete block are screened according to the business chain code in the blockchain transaction generation process to generate a business block in the corresponding business domain, and the block body of the generated business block includes all blockchain transactions generated in the complete block using the same business chain code and the sequence number of each blockchain transaction in the complete block, and the block header of the business block includes the block number of the business block, the total number of blockchain transactions in the corresponding complete block, the business chain code name, and multi-value proof auxiliary information proving the existence of blockchain transactions in the business block.

[0010] As a dynamic expansion storage method for alliance chain ledgers based on state data collaboration of the present invention, further, in generating a business block of a business domain, it also includes: establishing a Merkle tree for blockchain transactions in a complete block, using the hash value recorded in the root node of the Merkle tree as the block body hash of the current complete block, and merging the Merkle proof paths for verifying each blockchain transaction using sparse Merkle multi-value proof to simultaneously verify the authenticity of all transaction data in the business block.

[0011] As a dynamic expansion storage method for alliance chain ledgers based on state data collaboration of the present invention, further, in merging the Merkle proof paths for verifying each blockchain transaction using sparse Merkle multi-value proof, according to the structure that all non-leaf nodes of the Merkle tree have two left and right child nodes, if there are two Merkle proof paths passing through the target Merkle tree node from the left and right child paths of one of the target Merkle tree nodes, the target Merkle tree node is calculated through the left and right child nodes of the target Merkle tree node, and the target Merkle tree node is used as an obtainable node that does not need to be recorded in the sparse Merkle multi-value proof auxiliary information.

[0012] As a method for dynamically expanding storage of alliance chain ledgers based on state data collaboration of the present invention, further, in the process of updating the business world state database stored in itself by using the blockchain transactions in the business block, the business node verifies the authenticity of the blockchain transactions in the business block based on the obtained business block, the complete block header and the business block blockchain transaction number list, and the verification process includes:

[0013] First, verify whether the block number contained in the business block header is consistent with the block number contained in the complete block header to match the business block with the complete block; verify whether the number of items recorded in the business block blockchain transaction list is the same as the actual number of blockchain items contained to ensure the accuracy of the number of transactions contained in the business block; and use multi-value proof auxiliary information to simultaneously verify the existence of blockchain transactions in the business block in the complete block;

[0014] Then, for the business blocks that have passed the verification, the business node uses the blockchain transactions contained in the business blocks to update the business world state database, and discards the business blocks after the update is successful.

[0015] As a dynamic expansion storage method of alliance chain account book based on state data collaboration of the present invention, further, constructing a hierarchical B+ tree of the business world state database corresponding to the business node, including: constructing a B+ tree of the business world state database corresponding to the business node, and establishing a data layer for storing data nodes in the B+ tree, a data index layer for using pointers to point to the corresponding data node key interval in the B+ tree, a hierarchical node layer for grouping B+ tree management data, and a consistency information layer for obtaining consistency information of B+ tree management data, each data node corresponds to a hierarchical identifier C i , data nodes are classified according to the data node level information, and each level node manages its own data nodes through the data index layer.

[0016] As a method for dynamically expanding storage of alliance chain ledgers based on state data collaboration of the present invention, further, in the data layer, data nodes are stored in the form of key-value pairs {brev m , data} form, brev m represents the key of data node m, data represents the content stored in the corresponding data node; in the data index layer, each level node indexes the data nodes of the corresponding level through a multi-branch tree, and stores the data node key brev in the multi-branch tree m The interval [brev m ,brev m+n ] and a pointer P pointing to the data node interval m～m+n ; The level nodes in the level node layer store the node corresponding level identifier, level data consistency information and a pointer to the index root node; in the consistency information layer, the hash of the level nodes is merged and calculated through a multi-branch tree, and the level node interval [C i ,C i+j ] identifies the consistency information node of the consistency information layer to indicate the level node range of the consistency information node identification, and obtains the root node H of the consistency information layer by hashing the consistency information node. part .

[0017] As a dynamic expansion storage method for alliance chain ledgers based on state data collaboration of the present invention, further, the consistency of the business world state data stored by the business nodes in the same business scenario is verified through the check side chain in the main-side chain cross-anchor structure, and it also includes: setting the check block height threshold to c, when c blocks are generated in the main chain, initiating a consistency check transaction to reach a consensus on the consistency of the business world state database maintained in each business domain, and generating a check block through a sorting service, wherein the check transaction contained in the check block is initiated by the master node in the master node domain, and when the main chain block height reaches the preset threshold, the corresponding master node constructs a hierarchical B+ tree for the business world state database of each business domain stored locally, obtains consistency information, and generates a check block for each business domain. Check transactions. The initiating node of the check transaction is taken turns by the main node in the system. When a business node finds that there are inconsistent data in the business world status database stored in itself, it requests the consistency information layer and level node layer data of the current main chain height level B+ tree from other business nodes in the business domain, and compares them with the consistency information layer and level node layer data obtained based on its own business world status database. If inconsistent level nodes are found, request the data layer data managed by the inconsistent level nodes from other nodes in the business domain, replace the inconsistent data layer data with the new data layer data, recalculate the consistency information of the business world status database, and compare it with the consistency information contained in the corresponding check transaction. If they are consistent, the business world status database is repaired.

[0018] As a dynamic expansion storage method for alliance chain ledgers based on state data collaboration of the present invention, further, the hierarchical nodes in the hierarchical B+ tree are used to divide the data in the business world state database into hot world state data stored by the business nodes and cold world state data stored by the storage device under the business domain chain, including: when the world state data in the business world state database is updated, the old version of the world state data is deleted, and a new version of the world state data is generated, and the new version of the world state data is managed by a new hierarchical node; the world state data with an update frequency less than the preset frequency is managed by the old hierarchical nodes of the next level, and the hierarchical nodes are used to distinguish between hot world state data and cold world state data.

[0019] Beneficial effects of the present invention:

[0020] The present invention divides the alliance chain world state database into different business world state databases according to the different business contents to be processed, and uses the hierarchical nodes of the hierarchical B+ tree to distinguish the hot world state data and the cold world state data in the business world state database. The hot world state data is stored by the business nodes, and the cold world state data is stored by the off-chain storage facilities in the business domain. Dynamic expansion is achieved by transferring the infrequently used world state data to the off-chain storage facilities, and the world state data is dynamically expanded and stored according to the update frequency. Under the premise of isolating the account book data between business domains, the collaborative storage of the state data by the business nodes in the organization is achieved. On the basis of the collaborative storage of the world state data, the storage pressure of the account book data of the blockchain nodes can be further reduced, which is convenient for application in various business scenarios in the alliance chain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a schematic diagram of the dynamic expansion storage process of the alliance chain account book based on the state data collaboration in the embodiment;

[0022] Figure 2 This is a schematic diagram of the B+ tree structure in the embodiment;

[0023] Figure 3 This is a schematic diagram of the collaborative storage principle of state data in the embodiment;

[0024] Figure 4 This is a schematic diagram of a collaborative storage architecture for state data in an embodiment;

[0025] Figure 5 It is a schematic diagram of generating a service block in the embodiment;

[0026] Figure 6 This is an illustration of the multi-value existence proof of the business block in the embodiment;

[0027] Figure 7 This is a schematic diagram of a hierarchical B+ tree in an embodiment;

[0028] Figure 8 This is a schematic diagram of the main-side chain cross-recording structure in the embodiment;

[0029] Fig. 9 This is a schematic diagram of the inspection block structure in the embodiment;

[0030] Fig.10 Schematic diagram of the world state data consistency comparison in the embodiment.

[0031] Fig.11 This is a comparison of the amount of ledger data stored in the embodiments;

[0032] Fig.12 This is an illustration of the ledger compression ratio (including only world state creation transactions) in the embodiment;

[0033] Fig.13 This is a comparison of the amount of ledger data stored in the embodiments;

[0034] Fig.14 This is an illustration of the ledger compression ratio (including world state creation and update transactions) in the embodiment. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solutions and advantages of the present invention clearer and more understandable, the present invention is further described in detail below in conjunction with the accompanying drawings and technical solutions.

[0036] In a big data environment, data is characterized by large volume, diverse types, and rapid changes. The alliance chain system used in this scenario faces the problem of excessive storage of ledger data. The ledger data for processing different types of business also needs to be isolated to ensure the security of the ledger data. Figure 1 As shown, a dynamic expansion storage method for alliance chain ledgers based on state data collaboration is provided. The alliance chain world state database is divided into different business world state databases according to different business scenarios. Each business node in the alliance chain stores the business world state database and the check side chain block header in its own business domain. The business world state database in each business domain is generated by the same business chain code; and the check side chain in the main-side chain cross-anchor structure is used to verify the consistency of the business world state data stored by the business nodes in the same business scenario, and a hierarchical B+ tree of the business world state database corresponding to the business node is constructed, and the hierarchical nodes in the hierarchical B+ tree are used to divide the data in the business world state database into hot world state data stored by the business node and cold world state data stored by the storage device under the business domain chain.

[0037] The consortium chain is composed of different organizations, and organizations are groups of different types of nodes. The consortium chain strictly authenticates and manages the nodes. The ledger data can only be accessed by nodes in the organization, which isolates the ledger data from external nodes. The submitting node in the consortium chain initiates blockchain transactions through chain codes. After endorsement, blockchain transactions are formed into blocks through the sorting service. Blocks are connected end to end to form a chain ledger. At the same time, the world state is stored using key-value pairs (key, value). The key is the identifier of the world state, and the value records the version number rev of the world state and other data related to the specific business scenario. The chain code of the consortium chain contains multiple smart contracts for business processing. The chain code can be used to create, query and update the world state data. When the world state is updated, its key remains unchanged, and the version number rev and other data related to the specific business scenario are updated.

[0038] In addition to the chain ledger and the world state database, the ledger data stored in the alliance chain node also includes a history database and an index database. The history database stores the location of the blockchain transaction that updates the world state data database in the chain ledger. The index database stores the specific location of the block in the chain ledger stored in the form of a file. Multiple accounting nodes in the organization store and maintain the alliance chain ledger, and access the stored ledger through the client.

[0039] B+ tree is a multi-way balanced search tree used to index and retrieve data in file systems or databases. Figure 2 As shown, the leaf nodes in the B+ tree store multiple data and are sorted in the order of increasing keywords of the data. Non-leaf nodes store the range of data stored in the leaf nodes and pointers to the leaf nodes. The data range stored in the non-leaf nodes can be used to quickly locate the data stored in the child nodes of the B+ tree, thereby achieving efficient data retrieval. The data stored in the B+ tree is stored in the order of increasing keywords of the data, which ensures the determinism of the data structure and facilitates the construction of a completely consistent data structure in a distributed data system.

[0040] In the embodiment of this case, the complete world state database is divided into different business world state databases according to the different business scenarios of the world state, and the alliance chain nodes of different business departments process different business world state data to realize the collaborative storage of the world state database. This idea can efficiently save the storage space of the alliance chain nodes, and can realize the safe isolation of the ledger data in different business scenarios. The chain ledger is divided into different fragments randomly or in the order of transactions and stored by different accounting nodes, which does not solve the problem of more communication and time costs when obtaining the ledger data that is not stored locally. The world state data exists in the form of a single key-value pair, which has a smaller granularity than the chain ledger composed of blocks. By dividing the world state database according to different business scenarios, the alliance chain nodes in different scenarios can store the world state data with the highest utilization rate, effectively improving the efficiency of querying the ledger data.

[0041] The state data in the consortium chain can improve the access speed of nodes to the ledger data and serve as the basis for determining the validity of the blockchain transaction read and write set. When initiating a blockchain transaction to perform a write operation on the ledger data, an endorsement policy can be set to stipulate that the blockchain transaction can only write new data into the ledger after verification by enough organizations. However, when initiating a blockchain transaction to read the world state, endorsements from multiple organizations are not required. The blockchain node obtains the corresponding state data from the locally stored state database and returns it to the applicant of the state data. After completing the write operation, the state database has a high degree of independence and is less secure than the chain ledger stored in a chain structure. If the data stored in the state database is damaged or maliciously modified, the operation of reading the state data has the risk of returning untrusted data. It is necessary to verify the consistency of the state data stored in the consortium chain node to ensure the security of the state data.

[0042] The state data collaborative storage architecture is used to collaboratively store and update the corresponding business world state data of business nodes in different business scenarios. Furthermore, the business node can be set to only receive business block data related to its own business and verify the authenticity of the blockchain transaction in the business block, so as to update the business world state database stored in itself using the blockchain transaction in the business block. The alliance chain sorting service is used to generate a complete block and the blockchain transactions in the complete block are screened according to the business chain code in the blockchain transaction generation process to generate the business block in the corresponding business domain. The block body of the generated business block contains all blockchain transactions generated by the same business chain code in the complete block and the sequence number of each blockchain transaction in the complete block. The block header of the business block contains the block number of the business block, the total number of blockchain transactions in the corresponding complete block, the name of the business chain code, and multi-value proof auxiliary information proving the existence of blockchain transactions in the business block.

[0043] See also Figure 3 As shown, in order to reduce the ledger storage pressure of the business node, the master node can periodically reach consensus on the consistency information of each business world state database and the main chain period interval summary, and use the check side chain for storage; the business node obtains the consistency information in the side chain block and compares it with its own information to ensure the consistency of the business world state database stored in itself.

[0044] In the state data collaborative storage architecture, participants in the alliance chain organization can be divided into organization managers and business departments. Taking the data sharing scenario as an example, the shared data can be divided into multiple different business types such as video data, text data, audio data and image data. Within the alliance chain organization, business departments can be set up for each data type, and all business departments within the organization can be managed by the organization manager. The organization manager builds the master node of the organization, and the business department builds its own business node. The master node and the business node are both accounting nodes in this solution. In this solution, the master node and the business node use different ledger data storage strategies. To ensure that the ledger data is fully available within the organization, the master node stores the complete alliance chain ledger, including the chain ledger, the world state database, the historical database, the index database and the inspection side chain proposed in this solution. A master node is set in each organization, and all master nodes constitute the master node domain. Business nodes in the same organization are responsible for different businesses, and form business domains with business nodes in other organizations responsible for the same business. Business nodes in the same business domain process the same type of business based on the same business chain code and maintain a consistent business world state database. Business nodes only store the business world state database in their respective business domains and check the side chain block header. The business world state database is a type of data that processes the same business in the complete world state database. The business world state database in a business domain is generated by the same chain code. Figure 4 As shown in the figure, there are 3 business nodes in each of the three business domains a, b, and c, and these 3 business nodes belong to organization 1, organization 2, and organization 3 respectively; the 3 business nodes in business domain a process the business involved in business a according to chain code a, and store the business world state database a. The storage of complete world state data in the system is realized by collaborative storage of business world state databases in different business domains, so as to effectively reduce the ledger storage pressure of business nodes and help the alliance chain system to handle more business. Business nodes can only obtain the business world state database in their business domain, which realizes the controllable access of business nodes to the alliance chain ledger data.

[0045] In the embodiment of this case, in the business block of the generated business domain, it also includes: establishing a Merkle tree for the blockchain transactions in the complete block, using the hash value recorded in the root node of the Merkle tree as the block body hash of the current complete block, and merging the Merkle proof paths that verify each blockchain transaction using sparse Merkle multi-value proof to simultaneously verify the authenticity of all transaction data in the business block. According to the structure that all non-leaf nodes of the Merkle tree have two left and right child nodes, if there are two Merkle proof paths that pass through the target Merkle tree node from the left and right child paths of one of the target Merkle tree nodes, the target Merkle tree node is calculated through the left and right child nodes of the target Merkle tree node, and the target Merkle tree node is used as an available node that does not need to be recorded in the sparse Merkle multi-value proof auxiliary information.

[0046] The master node updates the stored world state database according to the blockchain transactions contained in the complete block. The complete block contains a block header and a block body. The block header stores the block body hash of the block, the block header hash of the previous block, and the block number. The block body of the complete block stores blockchain transactions in the order of consensus, involving all businesses in the system. A Merkle tree is constructed for the blockchain transactions contained in the complete block, and the hash value recorded by the root node of the Merkle tree is used as the block body hash of the block. The complete block contains blockchain transactions of different business domains. In order to prevent business nodes from obtaining transaction data of other business domains and realize controllable access to ledger data, business nodes cannot directly obtain complete blocks to update the business world state database. In this regard, this solution proposes the concept of business blocks. Business nodes only receive business blocks related to their own business, and use the transactions to update their own stored business world state database on the basis of verifying the authenticity of blockchain transactions in business blocks.

[0047] The consortium chain ordering service (Ordering Service) is a technology that ensures a consistent blockchain transaction order in the consortium chain system. It can sort multiple concurrent blockchain transactions in the consortium chain system and obtain globally recognized transaction numbers in the block, ensuring the certainty of the blockchain transaction order in the consortium chain system. At the same time, the ordering service can classify blockchain transactions according to the parameter information contained in the blockchain transactions, and distribute the classified data to specific consortium chain nodes. In this solution, the business in the same business domain is managed by a chain code, and the chain code is used to initiate blockchain transactions to implement the processing of business in the business domain. The name of the chain code used to generate the blockchain transaction is recorded in the blockchain transaction. The process of generating business blocks in this solution is as follows: Figure 5As shown in the figure, the sorting service filters the blockchain transactions in the complete block according to the business chain code that generates the blockchain transaction to obtain the business blocks of each business domain. The block body of the business block contains all the blockchain transactions generated by the same business chain code in the complete block, as well as the sequence number of each blockchain transaction in the complete block.

[0048] Since the transaction data contained in the business block is part of the transaction data in the complete block, the business node cannot directly use the Merkle tree root hash in the complete block header to verify the authenticity of the transaction data contained in the business block. It is necessary to use Merkle proofs to verify each transaction, which will bring large communication and storage overhead. In this regard, in the embodiment of this case, sparse Merkle multi-value proofs can be used to merge the Merkle proof paths that verify each transaction, so as to achieve simultaneous verification of the authenticity of all transaction data in the business block. The block header of the business block contains the block number blockNum of the business block, the total number of blockchain transactions in the corresponding complete block Tx_Total_Num, the business chain code name chaincode_name, and the multi-value proof auxiliary information Multiproofs_Inf that proves the existence of blockchain transactions in the business block. The block number of the business block is consistent with the block number of its corresponding complete block.

[0049] Merkle tree nodes can be recorded in the form of key-value pairs {merkle_key,merkle_value}. The key merkle_key is graded and expressed as The superscript i indicates the layer where the Merkle tree node is located in the Merkle tree. i=0 indicates that the node is obtained by calculating the blockchain transaction hash. i>0 indicates that the node is obtained by merging two child nodes. i=Root indicates that the node is the root node of the Merkle tree. The larger the i, the closer the node is to the root node of the Merkle tree. The subscript j indicates the sequence number of the node in the i-th layer. The subscripts of each layer of the Merkle tree node increase from left to right. The value merkle_value indicates the hash value recorded by the Merkle tree node. All non-leaf nodes of the Merkle tree have left and right child nodes. If two Merkle proof paths pass through the Merkle tree node from the left and right child paths of a Merkle tree node respectively, the Merkle tree node can be obtained by calculating the left and right child nodes of the Merkle tree node. The Merkle tree node is an available node and does not need to be recorded in the auxiliary information of the sparse Merkle multi-value proof.

[0050] like Figure 6In the schematic diagram of generating multi-valued proof auxiliary information for the set business block, t0~t7 represent transactions in the complete block, where {t0, t2, t3, t6} are transactions included in a business block. It is necessary to verify the existence of {t0, t2, t3, t6} in the complete block at the same time. When performing Merkle proof on blockchain transaction t2, the Merkle proof path is And need to prove auxiliary information When performing Merkle proof on blockchain transaction t3, the Merkle proof path is And need to prove auxiliary information The two proof paths start from the Merkle tree node If the left and right subpaths pass through this node, then we can use the existing nodes in the two proof paths and Get Node Then the auxiliary information proving the simultaneous existence of blockchain transactions t2 and t3 is Similarly, the multi-valued proof auxiliary information that simultaneously verifies the existence of blockchain transactions {t0, t2, t3, t6} is

[0051] The master node of each organization connects to the sorting service to obtain the complete block generated by the sorting service, and in each organization, the block header of the complete block and the list of the number of transactions in the business block blockchain Amount list Broadcast, Amount list Record the number of transactions contained in each business block. Each business domain elects a business docking node to connect with the sorting service, obtains the business blocks of their respective business domains, and broadcasts them in their respective business domains.

[0052] Specifically, in the embodiment of this case, the business node can verify the authenticity of the blockchain transaction in the business block based on the obtained business block, the complete block header and the business block blockchain transaction list. The verification process can be designed to include the following contents:

[0053] First, verify whether the block number contained in the business block header is consistent with the block number contained in the complete block header to match the business block with the complete block; verify whether the number of items recorded in the business block blockchain transaction list is the same as the actual number of blockchain items contained to ensure the accuracy of the number of transactions contained in the business block; and use multi-value proof auxiliary information to simultaneously verify the existence of blockchain transactions in the business block in the complete block;

[0054] Then, for the business blocks that have passed the verification, the business node uses the blockchain transactions contained in the business blocks to update the business world state database, and discards the business blocks after the update is successful.

[0055] The business node obtains the business block, the block header of the complete block and the amount list After that, the authenticity of the transaction in the business block is verified. First, verify whether the block number contained in the business block header is consistent with the block number contained in the complete block header to ensure that the business block matches the complete block. Then, verify the Amount list Whether the number of records in the transaction is the same as the actual number of blockchains included, ensure that the number of transactions in the business block is correct. Finally, this solution designs a layer-by-layer verification method to implement the verification of sparse Merkle multi-value proofs, and uses multi-value proof auxiliary information to simultaneously verify the existence of blockchain transactions in the business block in the complete block.

[0056] The total number of blockchain transactions Tx_Total_Num recorded in the business block header is used to calculate the number of layers I of the Merkle tree, where I satisfies 2 I-1 <Tx_Total_Num<=2 I . Calculate the hash of the blockchain transaction in the business block as the value merkle_value of the bottom node of the Merkle tree, and obtain the key merkle_key corresponding to each value merkle_value, where the superscript i is 0 and the subscript j is the sequence number of each blockchain transaction in the complete block, and record the obtained node in the Merkle tree at the 0th layer Merkle_level0.

[0057] When the subscript j of the key merkle_key is an even number, it means that the node is connected to the upper node through the left subpath, and when the subscript is an odd number, it means that the node is connected to the upper node through the right subpath. Analyze the nodes in Merkle_level0 one by one in the ascending order of the subscript of the key merkle_key. When the subscript j of the node key merkle_key is an even number, check whether there is a node with a subscript j+1 in Merkle_level0. If not, obtain it in the multi-value proof auxiliary information. If the subscript j of the node is an odd number, directly obtain the node with a subscript j-1 in the multi-value proof auxiliary information. Use the two obtained left and right child nodes to calculate the first-level node of the Merkle tree. The superscript of the obtained node key is 1, and the subscript is 1 / 2 of the subscript of the left child node, and it is recorded in the first-level Merkle_level1 of the Merkle tree. Then, the nodes in Merkle_level1 are processed in the same way as Merkle_level0 to obtain the Merkle tree nodes in the upper Merkle_level2 until the root node of the Merkle tree is obtained. The hash value recorded in the root node is compared with the block body hash recorded in the complete block header. If they are consistent, it proves that the blockchain transactions contained in the business block are all derived from the corresponding complete block.

[0058] After the business block is verified, the business node uses the blockchain transactions contained in the business block to update the business world state database. After the business world state database is successfully updated, the business node discards the business block.

[0059] like Figure 6 The blockchain transaction to be proved in is {t0, t2, t3, t6}, then The multi-valued proof auxiliary information recorded in the block header of the business block is Analyze the nodes in Merkle_level0 in ascending order of the subscript of the key merkle_key. If the node's subscript is an even number 0, first look for a node with an odd number 1 in Merkle_level0. If the node does not exist in Merkle_level0, obtain the node in the multi-value proof auxiliary information. use and Calculate upper node And the node Recorded in Merkle_level1, After that, for the nodes in Merkle_level0 Conduct analysis, The subscript of is an even number 2, then first search in Merkle_level0 to see if there is a node with the key merkle_key subscript of an odd number 3. From Merkle_level0, we can find that there is a node use and Calculate upper node And the node Recorded in Merkle_level1, Then the nodes in the hash group Analyze and convert the nodes Recorded in Merkle_level1, Then, Merkle_level1 is analyzed in the same way as Merkle_level0 to obtain Merkle_level2, until the root node of the Merkle tree is obtained. This enables the authenticity verification of the business block and the update of the business world status database.

[0060] In order to reduce the storage pressure of business node ledgers, business nodes in this solution do not store chained ledgers. Business nodes cannot verify the consistency of the business world state database stored by different business nodes in the same business domain by reconstructing the world state database based on chained ledgers. In this regard, the consistency verification of the world state data based on the hierarchical B+ tree can be used. First, the hierarchical B+ tree is improved to obtain the consistency information of the business world state database and use the information to initiate a check transaction. The main chain and the check side chain information are matched through the main side chain anchoring structure. The business node verifies the consistency of the business world state database stored in itself by obtaining the consistency information in the check block. Specifically, constructing a hierarchical B+ tree of a business world state database corresponding to a business node may specifically include the following contents: constructing a B+ tree of a business world state database corresponding to a business node, and establishing a data layer for storing data nodes in the B+ tree, a data index layer for using pointers to point to a key interval corresponding to a data node in the B+ tree, a hierarchical node layer for grouping B+ tree management data, and a consistency information layer for obtaining consistency information of B+ tree management data, where each data node corresponds to a hierarchical identifier C i , data nodes are classified according to the data node level information, and each level node manages its own data nodes through the data index layer.

[0061] The B+ tree sorts the keywords of the data in ascending order, ensuring the certainty of the data structure. However, when the data is damaged, the B+ tree cannot be used to determine whether the data structure is consistent, and the specific location of the data damage cannot be found. In this regard, in the embodiment of this case, the B+ tree is improved to propose a hierarchical B+ tree, such as Figure 7 As shown. On the basis of the original B+ tree structure, a hierarchical node layer is constructed to group the data managed by the B+ tree, and the hash value of the sorted data group is calculated as the consistency information of the group of data. The consistency information of all data managed by the hierarchical B+ tree is obtained through the consistency information layer. There are four layers in the hierarchical B+ tree, which are the consistency information layer, hierarchical node layer, data index layer and data layer from top to bottom.

[0062] The data layer stores data nodes, which are represented by key-value pairs, represented as {brev m , data}, where brev m Indicates the key of the data node, and data indicates the content stored in the data node. The data node corresponds to a level identifier C i, classify the data nodes according to their level information, and manage the data nodes to which they belong through the data index layer. Each level node indexes the data nodes of that level through a multi-branch tree, and stores the data node key brev in the multi-branch tree. m The interval [brev m ,brev m+n ] and a pointer P pointing to the data node interval m～m+n The data nodes in the data node interval are sorted according to the data node key brev m Sort in ascending order, key brev m The smallest data node is on the left, key brev m The largest data node is at the far right. Adjacent data node intervals are also stored in ascending order of keys, and the keys of the data nodes in the left data node interval are smaller than the keys of the data nodes in the right data node interval. Calculate the hash H of the sorted data nodes managed by each level node ci As the data consistency information of this level, Hc i = hash(sortedD ci ), where sortedD ci Represents level node C i The level node stores the level identifier C of the level node. i , level data consistency information Hc i And a pointer to the root node of the index.

[0063] In the consistency information layer, the ascending sorting method is also used to sort the level node identifier C in the level node layer. i To sort, the consistency information layer merges and calculates the hash of the level nodes through the multi-branch tree. ci～ci+j = hash(H ci ||H ci+1 ||H ci+2 ||...||H ci+j ). Use [C i ,C i+j ] The consistency information node of the consistency information layer is identified, indicating the range of the level node identified by the consistency information node. The consistency information node is also merged by hash merging, and finally the root node H of the consistency information layer is obtained. part .

[0064] In order to avoid affecting the generation of business blockchain transactions in the main chain, blockchain transactions cannot be initiated in the main chain to verify the consistency of the business world state data. In this regard, in the embodiment of this case, a consistency check side chain of the business world state database is set, and a check transaction is initiated in the check side chain to achieve consensus on the consistency information of the business world state database. The main side chain cross-anchoring structure is used, and the main side chain bidirectional recording method is adopted to achieve the matching of the main chain and the check side chain information, and at the same time, the security of the check side chain is enhanced. The main side chain cross-anchoring structure includes a blockchain main chain and a consistency check side chain. The main chain is the original chain in the alliance chain system. The check side chain uses the genesis block of the main chain as the starting block, and the remaining blocks are periodically generated check blocks. The generation of the check block is determined by the height of the main chain. Let the check block height threshold be c. When c blocks are generated in the main chain, a consistency check transaction is initiated to reach a consensus on the consistency of the business world state database maintained in each business domain, and a check block is generated through the sorting service.

[0065] The main side chain cross-anchor structure is as follows Figure 8 As shown in the figure, two main chain cycles [block_1, block_c] and [block_c+1, block_2c] are shown. When the block height of the main chain reaches c, a check transaction is initiated and the first check block cblock_1 is generated; when the block height of the main chain reaches 2c, the check side chain generates the second check block cblock_2. In this scheme, the block with a block height of nc in the main chain is called the main chain cycle point block, the range between two main chain cycle point blocks is called the main chain cycle interval, and the multiple n is called the checkpoint sequence number CheckNum corresponding to the main chain cycle interval. Figure 8 Where cycle_1 and cycle_2 are the main chain cycle intervals corresponding to the check blocks cblock_1 and cblock_2 respectively.

[0066] Check the structure of the block as Fig. 9As shown, the block header of the check block records the block header hash cblock_(i-1)_header_hash of the previous check block, the block body hash cblock_i_body_hash of the check block, the checkpoint sequence number CheckNum, and the block header hash block_cycle_i_header_hash of the corresponding main chain cycle point block block_cycle_i, and connects the check blocks in a chained manner to prevent the data in the check blocks from being tampered with. At the same time, a Merkle tree is constructed for the block headers of the main chain blocks within the main chain cycle interval, and the hash value recorded by the Merkle tree root node is obtained as the main chain cycle interval summary cblock_i_sum of the main chain cycle interval cycle_i, and it is stored in the block header of the check block cblock_i. Since the number of blocks generated in the side chain is small and the generation time interval is long, the latest check block has no subsequent blocks to record, and the security of the side chain block is reduced. In this regard, the main chain cycle point block records the information of the check block in the check side chain to ensure that the side chain block is credibly recorded in the chain structure of the blockchain. This scheme uses the block header of the main chain cycle point block block_cycle_i to record the block header hash of the previous check block cblock_(i-1).

[0067] The block body of the check block contains check transactions, which reach consensus on the consistency of the business world state database in each business domain at the current main chain block height. The business node obtains the consistency information recorded in the check transaction corresponding to its own business, and uses this information to perform consistency verification on the business world state database stored in itself. After the verification is passed, the block body of the check block is discarded and the block header of the check block is stored.

[0068] Furthermore, in the embodiment of the present case, the version number rev of the world state can be constructed in the form of a composite value, rev = CheckNum_BlockNum_TxNum_VerNum, and each sub-item is connected by an underscore. Suppose the blockchain transaction that generates the current version of the world state is TX, CheckNum is the checkpoint number corresponding to the main chain period interval where TX is located, BlockNum is the block number of the complete block where TX is located, TxNum is the serial number of TX in the complete block, and VerNum is the version number of the world state. The version number VerNum records the number of times the world state has been modified. When the world state is created, VerNum = 1. Each time the world state is updated, the version number VerNum is increased by 1. When the world state obtains the new version, the old version of the world state is deleted. Use CheckNum in the composite version number rev of the world state data as the identifier of the level node C iThe world state data updated within the same main chain cycle interval corresponds to the same checkpoint number CheckNum and the same level node. Use other parameters in the world state version number as the key brev of the data node, that is, brev = BlockNum_TxNum_VerNum. Each level node calculates the consistency information H of the level node for the world state data it manages through the data index layer and the data layer. ci , and then obtain the root node H of the consistency information layer part . H part Serves as the consistency information of the business world state database.

[0069] The check transaction contained in the check block is initiated by the master node in the master node domain. When the main chain block height reaches nc, the master node constructs a hierarchical B+ tree for the business world state database of each business domain stored locally and obtains consistency information. The check transaction for each business domain is constructed using the business domain name, checkpoint sequence number and consistency information. In order to prevent excessive reliance on a single master node, the initiating node of the check transaction is rotated by the master nodes in the system. The master node that does not serve as the initiating node verifies and endorses the check transaction to ensure the reliability of the check transaction. Set the warning duration t1 and the replacement duration t2, where t2>t1. If the current check transaction initiating master node does not initiate all check transactions within t1 time after the current main chain cycle point block block_cycle_i is generated, a warning is issued to the master node. If it is still not completed within t2 time, a certain penalty is imposed on the master node, and the remaining check transactions are initiated by the next check transaction initiating master node. After the check transaction is endorsed, the check block is generated through the sorting service and broadcast to all accounting nodes in the alliance chain system.

[0070] like Fig.10 As shown, the business node obtains the check block and extracts the consistency information of the business world state database that has been agreed upon from it, and uses the world state data stored by itself to build a hierarchical B+ tree and obtain the root node of the consistency information layer. The obtained root node information is compared with the consistency information obtained from the check transaction. If the two are consistent, it proves that the business world state data stored by itself is consistent with the business world state data stored in the master node domain, otherwise it means that there is inconsistent world state data in the business world state database stored by itself.

[0071] When a business node finds inconsistent data in its own business world status database, it requests the consistency information layer and level node layer data of the current main chain height level B+ tree from other business nodes in the business domain, and compares them with the consistency information layer and level node layer data obtained based on its own business world status database to find inconsistent level nodes. Then, it requests the data layer data managed by the inconsistent level nodes from other nodes in the business domain, and replaces the inconsistent data layer data with the new data layer data, recalculates the consistency information of the business world status database, and compares it with the consistency information contained in the corresponding check transaction. If they are consistent, the business world status database is repaired.

[0072] The version number of the world state data rev = CheckNum_BlockNum_TxNum_VerNum, where CheckNum is the checkpoint number corresponding to the main chain period interval where TX is located. When the world state data is updated, the CheckNum in the world state data version number is updated, which means that the world state is managed by the new level node and the old version of the world state data is deleted. The world state data that is not frequently updated is managed by the older level node, and the level node can effectively distinguish the commonly used hot world state data and the infrequently used cold world state data. The hot world state data is stored by the business node, and the cold world state data is stored by the off-chain storage facility in the business domain. Dynamic expansion is achieved by transferring the infrequently used world state data to the off-chain storage facility. When the account data pressure of the business node in the collaborative storage method is still large, the business node can transfer the infrequently used cold world state data to the off-chain storage facility in the business domain for storage, realize the dynamic expansion of the account data storage, further reduce the account data storage pressure of the business node, and effectively avoid the problem that the amount of account data storage exceeds the upper limit of the business node storage capacity.

[0073] In this embodiment, the business block is generated through the sorting service of the alliance chain, and each business domain elects its own business docking node. The sorting service connects with each business docking node and distributes the business block, building a business block propagation channel directly connected to the business domain by the sorting service. The distribution of business blocks does not rely on the intervention of a central organization, ensuring that the business block distribution process is highly decentralized. Business nodes in the same business domain receive the block header of the complete block from their respective organizations and the business block blockchain transaction number list Amount list The business node does not need to fully trust the business docking nodes in the business domain, and can verify whether the number of blockchain transactions contained in the business block is consistent with the Amount. listThe business node checks the business block to ensure the authenticity of the number of blockchain transactions in the business block and prevents the malicious deletion of blockchain transactions; and uses the received multi-value proof auxiliary information and the blockchain transactions contained in the business block to calculate the root node of the sparse Merkle multi-value proof. The hash value recorded in the root node is compared with the block body hash recorded in the complete block header to ensure the authenticity of the blockchain transactions contained in the business block. When the business node in the business domain finds that the business block received from the business docking node does not correctly match the verification information obtained from the respective organizations, the business node that finds the problem reaches a consensus with other business nodes in the business domain on the cause of the error, and then determines whether the behavior of the business docking node is credible. When it is found that the business docking node has untrustworthy behavior, the untrustworthy business docking node is replaced and a certain penalty is imposed. The business node can use the blockchain transactions contained in the verified business block to update the business world state database stored in it, so as to achieve the consistency of the business world state database stored by different business nodes in the same business domain, and keep the ledger data synchronized with the main chain at the same height. During the entire process, business nodes will not access the ledger data in other business domains, achieving secure isolation of ledger data between different business domains, ensuring controllable access to ledger data by business nodes, and ensuring a high degree of decentralization.

[0074] In the alliance chain system, the world state database is an extraction of important information from the chained ledger. It has high independence and does not have a chained structure similar to the end-to-end connection to ensure the security of the world state database. Data damage is more difficult to detect than the chained ledger. In order to achieve a more efficient reduction in the amount of ledger data storage of the business node, in the embodiment of this case, the business node does not store the chained ledger of the main chain, and cannot use the chained ledger backtracking method to restore the damaged business world state database. The need for consistency verification of the business world state database in the same business domain is more significant. By constructing a hierarchical B+ tree for the business world state database, the data layer of the hierarchical B+ tree sorts the world state data in a fixed order through the composite key BlockNum_TxNum_VerNum, and by calculating the hash of the sorted data layer data, the consistent ledger data in the same business domain can obtain the same hierarchical node layer and consistency information layer, and then obtain the same consistency information H of the business world state database. part. The damaged business world status database stores ledger data that is inconsistent with the normal nodes in the business domain, causing the data layer of the hierarchical B+ tree it constructs to be inconsistent with the normal nodes. Then, by comparing the information of the hierarchical node layer and the consistency information layer, it is possible to find the main chain cycle interval to which the damaged data belongs, accurately locate the damaged position of the business world status database, and reduce the cost of restoring the business world status database. At the same time, the consistency verification process of the business world status database is implemented by initiating a consistency verification transaction. The consistency verification transaction needs to be audited and endorsed by multiple organizations to ensure the credibility of the information recorded in the consistency verification transaction.

[0075] The chain structure of blockchain enhances the security of block data by connecting end to end. The block extracts the block header hash of the previous block and stores it in its own block header. This means that if a block in the middle of the chain is modified, the tampering behavior can be verified by the hash recorded in the next block connected to it. If the tamperer expects that his tampering behavior of the block will not be discovered, it is necessary to modify the hash recorded in the block header of all subsequent blocks of the block. The chain structure of blockchain increases the cost of tampering with block data, but the newer the block, the fewer subsequent blocks are connected to it, and the cost of tampering is lower. In this case, each check block in the side chain of the embodiment checks that it corresponds to a main chain cycle interval, and the check block has the characteristics of a small number of generated blocks and a long interval between generated blocks. The consistency check transaction of the business world state database is recorded in the block body of the check block, and the main chain cycle interval summary is stored in the block header of the check block. By storing the block header of the check block, the business node can verify the authenticity of the complete blockchain transaction and occupy less storage space for the account data. However, the small number of check blocks generated and the long interval between generated blocks also make the security of the check blocks weaker than that of the main chain blocks. This solution enhances the security of the check side chain through the main-side chain cross-anchoring structure. The block header hash of the check block corresponding to the previous main chain cycle interval is recorded in the main chain cycle point block, so that the block information of the check side chain can be recorded in the main chain. After the main chain cycle point block is generated, the main chain block continues to generate quickly and stores the side chain information inside the main chain, so that the side chain block is more securely protected. If an attacker wants to tamper with the check block of the check side chain, he needs to modify a large number of main chain blocks at the same time, thereby enhancing the security of the side chain.

[0076] In order to verify the effectiveness of this solution, the following is a further explanation based on experimental data:

[0077] The Go language is used to develop based on the alliance chain open source platform Hyperledger Fabric, implement and test the solution. The Go language version used is 1.16.4 and the Hyperledger Fabric version is 2.2. The experiment uses a 32-core 256GB memory Linux operating system computer, the CPU is Intel Xeon (Skylake) Platinum 8163, and the CPU main frequency is 2.5GHz.

[0078] By using Docker containers, we set up three organizations {org1, org2, org3}, each of which contains five accounting nodes {main_peer0_org i ,part_peer1_org i ,part_peer2_org i ,part_peer3_org i ,part_peer4_org i}, where 1≤i≤3. The 5 accounting nodes include 1 master node main_peer0_org i With 4 business nodes {part_peer1_org i ,part_peer2_org i ,part_peer3_org i ,part_peer4_org i}. Set up 4 business domains, and each organization's 4 business nodes join one business domain respectively. Set the number of blockchain transactions contained in each main chain block to Tx_Total_Num = 128, and set the check block height threshold c = 1024, then the number of blockchain transactions in a main chain cycle interval is cycle_txcount = Tx_Total_Num × c = 131072. Assuming that the probability of each blockchain transaction belonging to each business domain is the same, within a main chain cycle interval, the average number of new transactions in a single business domain is cycle_part_txcount = cycle_txcount / 4 = 32768. Use the sample network provided by Hyperledger Fabric to build a system containing 3 organizations, each of which contains 5 accounting nodes as the control system of this solution. The accounting nodes in the control system are represented as fabric nodes, and the ledger data stored in the fabric nodes include chain ledgers, world state databases, historical databases, and index databases. The blockchain transactions initiated in this solution system and the control system are the same.

[0079] The experimental part first tests the storage capacity of business node ledger data, and compares the storage capacity of business node ledger data with the storage capacity of fabric nodes in the control system. Then, the type of blockchain transaction is changed to analyze the impact of different types of blockchain transactions on the storage capacity of business node ledgers in the alliance chain system. The business node stores the business world state data and the block header of the check side chain. The proportion of the block header of the check side chain in the ledger data storage of the business node is tested to verify the impact of the block header data of the check side chain on the business node ledger storage. The alliance chain can realize most of the functions of the alliance chain system by operating the world state database. The retrieval efficiency of the business world state data stored by the business node of this solution and the world state data stored by the fabric node in the control system is tested to verify the efficiency of the business node in this solution in obtaining the world state data.

[0080] 1. Book data storage volume test: Generate the same blockchain transaction in this solution system and the control system, and store the blockchain book data. Compare the book volume of the business node in this solution system with the book volume of the fabric accounting node in the control system.

[0081] First, the change in node ledger data storage capacity is tested when all initiated transactions are world state creation transactions. At the end of the main chain cycle, the average ledger data storage capacity of the business nodes in this solution system and the average ledger data storage capacity of the fabric nodes in the control system are tested respectively. Fig.11 The chart shows the changes in the amount of ledger data storage of business nodes and fabric nodes within 20 main chain cycles. When the main chain cycle number is 2, the system of this solution and the control system generate 2×cycle_txcount=262144 pieces of world state data respectively, and the average number of world state data stored by a single business node is 262144 / 4=65536. The average amount of ledger data storage of fabric nodes in the control system is 1129Mb, and the average amount of ledger data storage of business nodes in this solution is 30Mb. When the main chain cycle number is 20, the system of this solution and the control system generate 20×cycle_txcount=2621440 pieces of world state data respectively, and the average number of world state data stored by a single business node is 2621440 / 4=655360. The ledger data storage of fabric nodes in the control system is 11254Mb, and the average amount of ledger data storage of business nodes in this solution is 292Mb.

[0082] For a more accurate comparison, the ratio of the business node ledger data storage volume in this solution to the fabric node ledger data storage volume in the control system is calculated to obtain the compression ratio com_ratio = size_part / size_fabric. The smaller the compression ratio, the smaller the space that the business node in this solution can occupy for the storage of ledger data relative to the fabric node in the control system. Calculate the compression ratio within 20 main chain cycles and obtain Fig.12 When all transactions are to create world state, the average amount of business node ledger data storage in this solution is 2.6053% of the fabric node ledger data storage in the control system. This solution can effectively reduce the amount of business node ledger data storage.

[0083] 2. Test on the impact of blockchain transaction types on ledger data storage capacity: All initiated blockchain transactions are transactions for creating world states. In the actual application of the alliance chain system, blockchain transactions for updating the world state are used more frequently. Different types of blockchain transactions will have different impacts on the blockchain ledger. In order to test the changes in ledger data storage capacity when the alliance chain system contains different proportions of world state creation and update transactions, a world state data update transaction is initiated based on the ledger data storage capacity test experiment, and the ledger storage capacity of the business nodes in this solution is tested and compared with that of the fabric nodes in the control system. Fig.13 As shown in the figure, all blockchain transactions from the 21st main chain cycle to the 60th main chain cycle are world state update transactions, and no new world state is created.

[0084] Depend on Fig.13 It can be seen that as the number of world state update transactions increases, the amount of ledger data stored in the fabric nodes in the control system is still growing at a relatively fast rate, while the storage capacity of the business nodes in this solution remains basically unchanged. The creation and update of the world state will increase the blockchain ledger data. The difference is that the world state creation transaction will add records to both the chained ledger and the world state database; the world state update transaction will increase the amount of chained ledger data, but will not generate new world state data, which has little impact on the amount of world state database data. Calculate the compression ratio from the 21st main chain cycle to the 60th main chain cycle to obtain Fig.14. As can be seen from the figure, as the proportion of world state update transactions gradually increases, the compression ratio of the ledger data of the business node and the fabric node in this solution gradually decreases. When the main chain cycle number is 40, 40×cycle_txcount=5242880 blockchain transactions are generated in the system of this solution and the control system respectively, and the ratio of world state creation transactions to world state update transactions is 1:1. At this time, the business node ledger data storage volume is 1.38% of the fabric node ledger data storage volume in the control system; when the main chain cycle number is 60, 60×cycle_txcount=7864320 blockchain transactions are generated in the system of this solution and the control system respectively, and the ratio of world state creation transactions in the system to world state update transactions in the system is 1:2. At this time, the business node ledger data storage volume is 0.95% of the fabric node ledger data storage volume in the control system. It shows that the higher the proportion of world state update transactions, the better the storage space saving performance of the business node ledger in the system of this solution.

[0085] Table 1 Comparison of solutions

[0086]

[0087] Among them, the existing method a is the unrelated block filtering method UBOF. According to the actual application scenarios of the industrial Internet of Things, the blocks that cannot be called by subsequent blockchain transactions are filtered, and the dynamic storage nodes only store the blocks that can be called subsequently. This solution is closely related to the actual application scenarios and is not suitable for scenarios where existing blocks may be called by subsequent transactions; the existing method b is a method of encoding blockchain transactions using the residual number system RNS. The blockchain node can dynamically adjust the compression ratio according to its own storage capacity to adapt to the growth of the ledger data scale. For the method of encoding the complete block into different shard blocks using encoding technology, when the node needs to obtain the complete block, it needs to initiate a shard block request to other nodes in the blockchain system and encode the shard block, which will consume more time compared to the system using the complete block; the existing method c is to store the blockchain transactions generated by the miner node in the IPFS network, and package the transaction storage address returned by the IPFS network into blocks instead of the original blockchain transaction for storage , using the characteristic that storage addresses occupy less storage space to save on-chain storage space; the existing method d is SlimChain, where off-chain nodes store part or all of the ledger data according to their own storage capacity and complete the verification of transaction validity; on-chain nodes only store transaction hashes and part of the block header data such as the hash value of the previous block, and based on these data, it can be verified whether the ledger data stored by the off-chain nodes has been tampered with; the above-mentioned method of transferring ledger data to off-chain storage space can dynamically adjust the demand for off-chain storage space as the amount of ledger data changes, but this type of technology transfers the ledger data from the blockchain accounting node to the off-chain ledger storage node, which reduces the degree of decentralization of the blockchain system, and it is necessary to ensure the security of off-chain ledger data storage to prevent the ledger data from being destroyed.

[0088] Table 1 compares this solution with existing research. It can be found that this solution can achieve better compression rate than existing solutions and can better save the storage space of accounting nodes. The compression rate achieved by existing method d and this solution is close, but the accounting node on the chain in the existing method d only stores data such as the blockchain transaction hash and the hash of the previous block. When the accounting node needs the ledger data, it needs to initiate a request to obtain the ledger data from the off-chain storage node that stores the complete blockchain ledger data, and needs to verify the authenticity of the obtained ledger data, which requires more time and communication consumption. In this solution, the ledger data is stored by the on-chain nodes, and the business nodes can efficiently obtain the required ledger data by retrieving the locally stored business world state database.

[0089] When the ledger data pressure of the business nodes in the above-mentioned collaborative storage method is still relatively large, the hierarchical nodes of the hierarchical B+ tree can be used to distinguish the hot world state data and the cold world state data in the business world state database. The hot world state data is stored by the business nodes, and the cold world state data is stored by the off-chain storage facilities in the business domain, thereby realizing the dynamic expansion of the ledger data storage.

[0090] Based on the above experimental data, the collaborative storage of the world state database in the alliance chain system by business nodes in this case can effectively reduce the ledger storage pressure of business nodes in the alliance chain system, and realize the isolation of ledger data between different business domains, ensuring the controllable access of business nodes to ledger data; by constructing a hierarchical B+ tree for the business world state database stored by the business node, and on this basis, initiating a consistency verification transaction by checking the side chain, the consistency of the business world state data stored by the business node can be verified; the main-side chain cross-anchoring structure is used to anchor the check side chain to the main chain, which can ensure the matching of side chain data with the main chain data and improve the security of side chain data; on the premise of ensuring that the ledger data has a high degree of decentralization and retrieval efficiency, it can achieve efficient saving of ledger data storage space of alliance chain business nodes, which is convenient for the deployment and implementation of secure storage of ledger data in actual big data business scenarios such as data circulation and sharing, data confirmation, and data traceability.

[0091] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present invention.

[0092] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0093] The units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation is not considered to be beyond the scope of the present invention.

[0094] Those skilled in the art will appreciate that all or part of the steps in the above method can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk or an optical disk. Optionally, all or part of the steps in the above embodiment can also be implemented using one or more integrated circuits, and accordingly, each module / unit in the above embodiment can be implemented in the form of hardware or in the form of software function modules. The present invention is not limited to any specific form of combination of hardware and software.

[0095] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for dynamically expanding storage of alliance chain ledgers based on state data collaboration, characterized in that: Include: The alliance chain world state database is divided into different business world state databases according to different business scenarios. Each business node in the alliance chain stores the business world state database in its own business domain and checks the side chain block header. The business world state database in each business domain is generated by the same business chain code. Construct a hierarchical B+ tree of the business world state database corresponding to the business node, use the hierarchical nodes in the hierarchical B+ tree to divide the data in the business world state database into hot world state data stored by the business node and cold world state data stored by the storage device under the business domain chain, and verify the consistency of the business world state data stored by the business node in the same business scenario through the check side chain in the main side chain cross-anchor structure. Constructing the hierarchical B+ tree of the business world state database corresponding to the business node includes: constructing a B+ tree of the business world state database corresponding to the business node, and establishing a data layer for storing data nodes in the B+ tree, a data index layer for using pointers to point to the corresponding data node key interval in the B+ tree, a hierarchical node layer for grouping B+ tree management data, and a consistency information layer for obtaining B+ tree management data consistency information, each data node corresponds to a hierarchical identifier C i , classify data nodes according to their level information, and manage their own data nodes through the data index layer; in the data layer, data nodes are represented by key-value pairs {brev m , data} form, brev m represents the key of data node m, data represents the content stored in the corresponding data node; in the data index layer, each level node indexes the data nodes of the corresponding level through a multi-branch tree, and stores the data node key brev in the multi-branch tree m The interval [brev m , brev m+n ] and a pointer P pointing to the data node interval m~m+n ; The level nodes in the level node layer store the node corresponding level identifier, level data consistency information and a pointer to the index root node; in the consistency information layer, the hash of the level nodes is merged and calculated through a multi-branch tree, and the level node interval [C i ,C i+j ] identifies the consistency information node of the consistency information layer to indicate the level node range of the consistency information node identification, and obtains the root node H of the consistency information layer by hashing the consistency information node. part The main-side chain cross-anchoring structure includes a blockchain main chain and a consistency check side chain. The blockchain main chain is the original chain in the alliance chain system. The consistency check side chain uses the genesis block of the blockchain main chain as the starting block, and the remaining blocks are periodically generated check blocks. The block body of the check block contains check transactions. The check transactions respectively reach consensus on the consistency of the business world state database in each business domain under the current blockchain main chain block height. The business node obtains the consistency information recorded in the check transaction corresponding to its own business, and uses the information to perform consistency verification on the business world state database stored in its own business. After the verification is passed, the block body of the check block is discarded and the block header of the check block is stored; and in the consistency verification process, the check block height threshold is set to c. When c blocks are generated in the blockchain main chain, a consistency check transaction is initiated to reach consensus on the consistency of the business world state database maintained in each business domain, and a check block is generated through the sorting service. Among them, the check transaction contained in the check block is generated by the main The master node in the node domain initiates. When the main chain block height reaches the preset threshold, the corresponding master node constructs a hierarchical B+ tree for the business world status database of each business domain stored locally, obtains consistency information, and generates a check transaction for each business domain. The initiator of the check transaction is the master node in the system in turn. When a business node finds that there is inconsistent data in the business world status database stored in itself, it requests the consistency information layer and hierarchical node layer data of the current main chain height hierarchical B+ tree from other business nodes in the business domain, and compares them with the consistency information layer and hierarchical node layer data obtained based on its own business world status database. If inconsistent hierarchical nodes are found, the data layer data managed by the inconsistent hierarchical nodes are requested from other nodes in the business domain, and the inconsistent data layer data is replaced with the new data layer data, the consistency information of the business world status database is recalculated, and compared with the consistency information contained in the corresponding check transaction. If they are consistent, the business world status database is repaired.

2. The method for dynamically expanding storage of alliance chain accounts based on state data collaboration according to claim 1 is characterized in that: For the business world state database, a state data collaborative storage architecture is used to collaboratively store and update the corresponding business world state data of business nodes in different business scenarios. Among them, the state data collaborative storage architecture divides the participants of the alliance chain organization into organization managers and business departments. The organization manager is used to build the master node for storing the complete alliance chain ledger in the corresponding business organization and manage all business departments within the business organization. The business departments build their own business nodes, and the master nodes of each business organization constitute the master node domain. The business nodes in the same organization are responsible for different businesses and constitute a business domain with the business nodes responsible for the same business in other business organizations. The business nodes are set to only receive business block data related to their own business. After verifying the authenticity of the blockchain transactions in the business block, the business world state database stored in itself is updated through the blockchain transactions in the business block.

3. The method for dynamically expanding storage of alliance chain accounts based on state data collaboration according to claim 2 is characterized in that: The business node is set to only receive business block data related to its own business, use the alliance chain sorting service to generate a complete block, and filter the blockchain transactions in the complete block according to the business chain code in the blockchain transaction generation process to generate a business block for the corresponding business domain. The block body of the generated business block includes all blockchain transactions generated in the complete block using the same business chain code and the sequence number of each blockchain transaction in the complete block. The block header of the business block includes the block number of the business block, the total number of blockchain transactions in the corresponding complete block, the business chain code name, and multi-value proof auxiliary information proving the existence of blockchain transactions in the business block.

4. The method for dynamically expanding storage of alliance chain accounts based on state data collaboration according to claim 3 is characterized in that: Generating a business block for a business domain also includes: establishing a Merkle tree for blockchain transactions in a complete block, using the hash value recorded in the root node of the Merkle tree as the block body hash of the current complete block, and simultaneously verifying the authenticity of all transaction data in the business block by merging the Merkle proof paths that verify each blockchain transaction using sparse Merkle multi-value proofs.

5. The method for dynamically expanding storage of alliance chain accounts based on state data collaboration according to claim 4 is characterized in that: In the Merkle proof path merging for verifying each blockchain transaction using sparse Merkle multi-value proof, according to the structure that all non-leaf nodes of the Merkle tree have two left and right child nodes, if there are two Merkle proof paths passing through the target Merkle tree node from the left and right child paths of one of the target Merkle tree nodes, the target Merkle tree node is calculated through the left and right child nodes of the target Merkle tree node, and the target Merkle tree node is used as an obtainable node that does not need to be recorded in the sparse Merkle multi-value proof auxiliary information.

6. The method for dynamically expanding storage of alliance chain accounts based on state data collaboration according to claim 4 or 5 is characterized in that: When using the blockchain transactions in the business block to update the business world state database stored in itself, the business node verifies the authenticity of the blockchain transactions in the business block based on the obtained business block, complete block header and business block blockchain transaction list. The verification process includes: First, verify whether the block number contained in the business block header is consistent with the block number contained in the complete block header to match the business block with the complete block; verify whether the number of items recorded in the business block blockchain transaction list is the same as the actual number of blockchain items contained to ensure the accuracy of the number of transactions contained in the business block; and use multi-value proof auxiliary information to simultaneously verify the existence of blockchain transactions in the business block in the complete block; Then, for the verified business blocks, the business node uses the blockchain transactions contained in the business blocks to update the business world state database and discards the business blocks after the update is successful.

7. The method for dynamically expanding storage of alliance chain accounts based on state data collaboration according to claim 1 is characterized in that: The hierarchical nodes in the hierarchical B+ tree are used to divide the data in the business world state database into hot world state data stored by the business nodes and cold world state data stored by the storage device under the business domain chain, including: when the world state data in the business world state database is updated, the old version of the world state data is deleted, and the new version of the world state data is generated, and the new version of the world state data is managed by the new hierarchical node; the world state data with an update frequency less than the preset frequency is managed by the old hierarchical node of the next level, and the hierarchical nodes are used to distinguish between hot world state data and cold world state data.

Images