Block chain data processing method and device, equipment and storage medium

Abstract

The embodiment of the invention discloses a block chain data processing method and device, equipment and a storage medium, and is applied to a block chain technology. The method comprises the following steps: receiving a synchronization request for a block chain; reading a first hash sub-chain associated with the first path from a first multi-way tree hash chain in the first block according to the first path information; reading block metadata of the first block from the first block, and reading a transaction corresponding to the first path from the first block according to the first path information; and synchronizing the block metadata of the first block, the first hash sub-chain and the transaction corresponding to the first path to a synchronization node device, the synchronization node device being used for verifying the validity of the transaction corresponding to the first path to obtain a verification result, and when the verification result indicates that the transaction corresponding to the first path has validity, sending the transaction to the first block. And storing the transactions corresponding to the first path. According to the invention, the consumption of network bandwidth can be reduced, and the waste of the storage space of the synchronous node equipment is avoided.

Description

Technical Field

[0001] The present application relates to fields such as blockchain technology, and in particular to a blockchain data processing method, device, equipment and storage medium. Background Art

[0002] Blockchain is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of online transactions, which is used to verify the validity of this information (to prevent counterfeiting) and generate the next block.

[0003] The term "blockchain synchronization node" refers to the node devices within the blockchain network responsible for synchronizing blockchain data. While synchronization node devices may not necessarily participate in the generation or verification of blocks, they are required to maintain the latest blockchain status for operations such as transaction queries and smart contract execution. Synchronization node devices can be lightweight clients or specialized blockchain service providers, communicating with consensus nodes or other synchronization node devices to obtain the latest blockchain data. Currently, when synchronization node devices synchronize blockchain data, consensus nodes must synchronize data across the entire blockchain. This results in a significant amount of unnecessary data transmission, especially for synchronization node devices that are only interested in specific transactions or blocks. This full synchronization method not only consumes significant network bandwidth but also wastes storage space on the synchronization node devices. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain data processing method, apparatus, device, and storage medium, which can reduce network bandwidth consumption and avoid wasting storage space of synchronization node devices.

[0005] On the one hand, an embodiment of the present application provides a blockchain data processing method, including:

[0006] receiving a synchronization request for a blockchain; the synchronization request carrying first path information, the first path information being used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicating a path by which the corresponding transaction reaches the blockchain, and at least two transactions in the first block having different paths to reach the blockchain;

[0007] Based on the first path information, a first hash subchain associated with the first path is read from a first multitree hash chain in the first block; the first multitree hash chain includes hash subchains for verifying transactions corresponding to each path in the first block.

[0008] Reading block metadata of the first block from the first block, and reading transactions corresponding to the first path from the first block based on the first path information;

[0009] The block metadata of the first block, the first hash subchain, and the transactions corresponding to the first path are synchronized to the synchronization node device. The synchronization node device is used to verify the validity of the transactions corresponding to the first path based on the first hash subchain and the block metadata of the first block, and obtain a verification result. When the verification result indicates that the transactions corresponding to the first path are valid, the transactions corresponding to the first path are stored.

[0010] On the one hand, an embodiment of the present application provides a blockchain data processing method, including:

[0011] Sending a blockchain synchronization request to a consensus node corresponding to the blockchain; the synchronization request carries first path information, the first path information being used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicating a path by which the corresponding transaction reaches the blockchain, and at least two transactions in the first block having different paths to reach the blockchain;

[0012] Receive the block metadata of the first block synchronized by the consensus node, the first hash subchain associated with the first path, and the transactions corresponding to the first path; the block metadata of the first block is read from the first block, the first hash subchain is read from the first multitree hash chain in the first block based on the first path information, the transactions corresponding to the first path are read from the first block based on the first path information, and the first multitree hash chain includes hash subchains for verifying the transactions corresponding to each path in the first block;

[0013] Verify the validity of the transaction corresponding to the first path based on the first hash subchain and the block metadata of the first block to obtain a verification result. When the verification result indicates that the transaction corresponding to the first path is valid, store the transaction corresponding to the first path.

[0014] An embodiment of the present application provides a blockchain data processing device, including:

[0015] a receiving module configured to receive a synchronization request for a blockchain; the synchronization request carrying first path information, the first path information being used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicating a path by which the corresponding transaction reaches the blockchain, and at least two transactions in the first block having different paths to reach the blockchain;

[0016] a first reading module, configured to read, according to the first path information, a first hash sub-chain associated with the first path from a first multi-tree hash chain in the first block, the first multi-tree hash chain including hash sub-chains for verifying transactions corresponding to each path in the first block respectively;

[0017] a second reading module, configured to read, from the first block, block metadata of the first block and a transaction corresponding to the first path from the first block according to the first path information;

[0018] a synchronization module, configured to synchronize the block metadata of the first block, the first hash sub-chain and the transaction corresponding to the first path to a synchronization node device, the synchronization node device being configured to verify validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtain a verification result, and store the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid.

[0019] Embodiments of the present application provide a blockchain data processing apparatus, which comprises:

[0020] a sending module, configured to send a synchronization request about a blockchain to a consensus node corresponding to the blockchain, the synchronization request carrying first path information, the first path information being used to synchronize a transaction corresponding to a first path in a first block to a synchronization node device, the first path indicating a path of the corresponding transaction to the blockchain, and there being at least two paths of transactions in the first block to the blockchain that are different from each other;

[0021] a receiving module, configured to receive block metadata of the first block, a first hash sub-chain associated with the first path and the transaction corresponding to the first path synchronized by the consensus node, the block metadata of the first block being read from the first block, the first hash sub-chain being read from a first multi-tree hash chain in the first block according to the first path information, and the transaction corresponding to the first path being read from the first block according to the first path information, the first multi-tree hash chain including hash sub-chains for verifying transactions corresponding to each path in the first block respectively;

[0022] a verification module, configured to verify validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtain a verification result, and store the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid.

[0023] The embodiment of the present application provides a computer device, which comprises a memory and a processor, the memory stores a computer program, and the processor implements the steps of the method when executing the computer program.

[0024] The embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the method.

[0025] The embodiment of the present application provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the method.

[0026] In the present application, the transactions in a block are organized in different paths, and a multi-tree hash chain for verifying the transactions corresponding to each path is stored in the block, that is, the multi-tree hash chain comprises hash sub-chains for verifying the transactions corresponding to each path, so as to realize a fine-grained block structure based on the multi-tree hash chain. When a transaction on a certain path (a first path) in a first block on the block chain needs to be read, only the hash sub-chain for verifying the transaction on the first path in the multi-tree hash chain, the block metadata in the first block and the transaction corresponding to the first path need to be synchronized to a synchronization node device, and the full amount of the first block does not need to be synchronized to the synchronization node device, so that unnecessary data transmission and storage are reduced, the consumption of network bandwidth is reduced, the synchronization efficiency is improved, and the waste of storage space of the synchronization node device is avoided. In addition, the synchronization node device can reduce the consumption of network bandwidth and avoid the waste of storage space of the synchronization node device. In addition, the synchronization node device can verify the validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, in other words, the synchronization node device only needs to verify the transaction of interest (the transaction corresponding to the first path), and does not need to verify all the transactions in the first block. This fine-grained verification method not only reduces the computing burden, but also improves the efficiency of the verification process, so that even a node with weak computing power can quickly complete data verification. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort.

[0028] Figure 1 It is a block chain data processing system schematic diagram provided by the present application;

[0029] Figure 2 is a flowchart of a blockchain data processing method provided by the present application;

[0030] Figure 3 is a scenario diagram of synchronizing transactions corresponding to the first hash sub-chain and the first path and block metadata provided by the present application;

[0031] Figure 4 is a scenario diagram of synchronizing transactions corresponding to the first hash sub-chain and the first path and block metadata provided by the present application;

[0032] Figure 5 is a scenario diagram of synchronizing transactions corresponding to the first hash sub-chain and the first path and block metadata provided by the present application;

[0033] Figure 6 is a scenario diagram of generating a second multi-tree hash chain provided by the present application;

[0034] Figure 7 is a flowchart of a blockchain data processing method provided by the present application;

[0035] Figure 8 is a schematic diagram of functional modules included in a consensus node device provided by the present application;

[0036] Figure 9 is a flowchart of adding a sub-chain or a subset provided by the present application;

[0037] Figure 10 is a flowchart of a block consensus storage based on a multi-tree hash chain provided by the present application;

[0038] Figure 11 is a flowchart of synchronizing node devices to synchronize block data of a specified granularity (a subset or a sub-chain) in a consensus node device provided by the present application;

[0039] Figure 12 is a structural diagram of a blockchain data processing apparatus provided by an embodiment of the present application;

[0040] Figure 13 is a structural diagram of a blockchain data processing apparatus provided by an embodiment of the present application;

[0041] Figure 14 is a structural diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0042] With reference to the drawings, the technical solutions in the embodiments of the present application will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of the present application.

[0043] The embodiments of the present application can be related to the blockchain technology. The so-called blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. The blockchain is essentially a decentralized database, which is a series of data blocks associated by using cryptographic methods, each data block contains the information of a batch of network transactions, and is used to verify the validity (anti-fake) of the information and generate the next block. The blockchain can include a blockchain underlying platform, a platform product service layer and an application service layer.

[0044] The blockchain underlying platform can include user management, basic services, smart contracts and operation processing modules. The user management module is responsible for the identity information management of all blockchain participants, including maintaining the generation of public and private keys (account management), key management and the maintenance of the correspondence between the real identity of the user and the blockchain address (permission management), and in the case of authorization, supervising and auditing the transaction of certain real identities, providing rule configuration for risk control (risk audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and after the consensus of valid requests, the information is recorded on the storage. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), then encrypts the business information through a consensus algorithm (consensus management), and after encryption, the complete and consistent information is transmitted to the shared ledger (network communication) and recorded and stored; the smart contract module is responsible for the registration and issuance of contracts, the triggering and execution of contracts, and developers can define contract logic through a certain programming language, publish it to the blockchain (contract registration), call keys or other events to trigger execution according to the logic of the contract terms, complete the contract logic, and also provide the function of contract upgrade and cancellation; the operation detection module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation in the product release process, and the real-time state visualization output in the product operation, such as alarm, network detection, node device health state detection, etc.

[0045] The platform product service layer provides basic capabilities and implementation frameworks for typical applications, and developers can add business characteristics based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on the blockchain solution for business participants to use.

[0046] The application belongs to the field of block data synchronization services, and specifically provides a multi-fork tree hash chain fine-grained block structure, so that the transactions in the blocks on the block chain can be synchronized to the synchronization node device according to the needs of the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, reducing unnecessary data transmission and storage, reducing the consumption of network bandwidth, improving synchronization efficiency, and avoiding waste of storage space of the synchronization node device.

[0047] Firstly, the terms involved in the application are explained as follows:

[0048] (1) Smart contract: a computer protocol designed to facilitate the spread, verification or execution of contracts in an information-based manner. Smart contracts allow trusted transactions without the need for a third party, and these transactions are traceable and irreversible.

[0049] (2) Consensus node device: a node device in the blockchain network responsible for verifying transactions and blocks. They reach data consistency in the network by running consensus algorithms. The purpose of the consensus algorithm is to ensure that all nodes agree on the state of the blockchain, even in the presence of malicious nodes, to maintain the normal operation of the network. Consensus node devices usually need to have high computing power and stable network connection, because they need to process a large amount of transaction data and participate in the generation and verification of blocks. Common consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS) and Byzantine Fault Tolerance (BFT).

[0050] (3) Synchronization node device: a node device in the blockchain network responsible for synchronizing data on the blockchain. They do not necessarily participate in the generation or verification of blocks, but need to keep the latest state of the blockchain data to perform operations such as transaction queries and smart contract execution. Synchronization node devices can be lightweight clients or professional blockchain service providers, which obtain the latest block data by communicating with consensus node devices or other synchronization node devices. In this application, synchronization node devices can selectively synchronize transactions in blocks, rather than downloading the entire blockchain transactions, which can save bandwidth and storage resources.

[0051] (4) Multi-tree Hash Chain: A data structure that organizes transactions in the blockchain in the form of a multi-tree (i.e., multiple paths). In this structure, each node represents a group of transactions, and nodes are connected by hashes. Compared with the traditional single-chain structure, the multi-tree structure can provide higher data processing efficiency and more flexible data organization. In the multi-tree hash chain, the hash of each node is calculated based on the hashes of its child nodes and possibly other information (such as the hash of the previous block or block metadata), which ensures the integrity and tamper resistance of the entire tree.

[0052] (5) Sub-chain, Subset: Sub-chain, subset refers to a part of transactions in a block on the blockchain, sub-chain is a branch of the blockchain, and subset can be a smaller data set in the sub-chain. In the context of multi-tree hash chain, sub-chain, subset can be a branch in the tree or a part of nodes in the branch. This data division allows consensus nodes to synchronize and verify specific data subsets (i.e., transactions corresponding to a certain path) as needed, rather than the entire blockchain, thereby improving data processing efficiency and flexibility, and achieving fine-grained data synchronization and verification through subsets and sub-chains.

[0053] In practice, it is found that the current blockchain data processing system has the following defects:

[0054] 1. Inefficient data synchronization: The current blockchain data processing system usually requires consensus node devices to synchronize the entire blockchain data to the synchronization node device, which leads to a large amount of unnecessary data transmission, especially for synchronization node devices that only care about specific transactions or blocks. This full-synchronization approach not only consumes a large amount of network bandwidth, but also puts higher requirements on the storage capacity of the synchronization node device, which is a significant disadvantage for resource-constrained synchronization node devices or network environments.

[0055] 2. Low verification efficiency: In the current blockchain data processing system, synchronization node devices must verify the entire blockchain data to ensure the integrity and correctness of the synchronized data. This full-chain verification method requires a large amount of computing resources, which can be a bottleneck for synchronization node devices with limited computing power. In addition, even if only interested in a certain block or transaction, the synchronization node device has to verify the entire blockchain data, which is obviously a waste of resources.

[0056] 3. Data security and integrity challenges: While traditional blockchain data systems focus on data immutability and integrity in design, in actual operation, if the synchronization node device attempts to synchronize or verify only part of the data, it may face challenges in security and integrity. Because in the absence of complete blockchain data, it is difficult to guarantee the coherence and consistency of the data, which may lead to security vulnerabilities, making the blockchain data system vulnerable to fork attacks or data tampering.

[0057] Therefore, the present application proposes a fine-grained block structure based on a multi-tree hash chain and a synchronization node device design scheme, which focuses on solving the above problems. The improvements of the present application are as follows:

[0058] ① Distributed selective data synchronization protocol: focuses on solving the data synchronization efficiency problem of the blockchain. By introducing a new protocol, it allows the synchronization node device to selectively synchronize the data (i.e. transactions) in the blockchain according to its own business needs, rather than synchronizing the entire blockchain data as in the traditional method. This method not only reduces the amount of data transmission and storage requirements, but also improves the synchronization speed, and is suitable for both resource-constrained environments and resource-unconstrained environments, expanding the application environment of the present application.

[0059] ② Multi-tree hash chain proof and verification framework: a new multi-tree hash chain proof structure is proposed, which organizes and verifies the data of the blockchain through a multi-dimensional data structure (such as a multi-tree). This framework not only enhances the traceability and security of the data, but also allows partial data verification without sacrificing integrity. This is particularly useful for application scenarios that require fast verification of specific data sets (subsets of transactions or subchains of transactions), such as the execution of smart contracts and data verification of lightweight synchronization node devices.

[0060] The present application has the following beneficial effects:

[0061] a. Improve synchronization efficiency and save resources: The present application uses a distributed selective data synchronization protocol (DSDSP) to allow synchronization node devices to synchronize specific data sets according to their own business needs, thereby significantly reducing unnecessary data transmission and storage, improving synchronization efficiency, and being suitable for both bandwidth and storage resource-constrained environments and bandwidth and storage resource-unconstrained environments, expanding the application environment of the present application.

[0062] b. Enhance the flexibility and efficiency of data verification: The multi-tree hash chain proof and verification framework (MHCPVF) of the present application allows nodes to verify only the data sets of interest, without the need to process the entire blockchain data. This fine-grained verification method not only reduces the computational burden, but also improves the efficiency of the verification process, so that even synchronization node devices with weak computing power can quickly complete data verification.

[0063] c. Ensuring data integrity and security: The present application ensures the integrity and tamper-proofing of data even when synchronizing and verifying partial data through the multi-tree structure and multi-tree hash chain calculation method. This is because the hash of each node of the multi-tree hash chain contains the hash of its child nodes and the hash related to the previous block, forming a coherent verification chain across blocks. This structure enhances the security of the blockchain, making any attempt to tamper with the data quickly discoverable and preventable.

[0064] In order to facilitate a clearer understanding of the present application, first introduce the blockchain data processing system for implementing the present application, as shown in Figure 1 The blockchain data processing system includes a consensus node cluster 10 and a synchronization node cluster 11. The consensus node cluster 10 can include multiple consensus node devices, which are not limited in number, as shown in Figure 1 For example, the consensus node cluster 10 includes four consensus node devices, and the consensus node cluster specifically includes consensus node device 101, consensus node device 102, consensus node device 103, and consensus node device 104. It can be understood that the consensus node device 101, consensus node device 102, consensus node device 103, and consensus node device 104 are network connected, so that each consensus node device can interact with each other through network connection.

[0065] The synchronization node cluster 11 can include one or more synchronization node devices, which are not limited in number, as shown in Figure 1 For example, the synchronization node cluster 11 includes four synchronization node devices, and the synchronization node cluster specifically includes synchronization node device 111, synchronization node device 112, synchronization node device 113, and synchronization node device 114. It can be understood that the synchronization node device 111, synchronization node device 112, synchronization node device 113, and synchronization node device 114 are network connected, so that each synchronization node device can interact with each other through network connection.

[0066] It should be noted that each synchronization node device and each consensus node device can be connected through a network connection, so that the consensus node device can synchronize the block metadata in the block on the blockchain, the transaction corresponding to the path, and the hash sub-chain to the synchronization node device.

[0067] It can be understood that the consensus node device and the synchronization node device can be an independent physical server, a server cluster or a distributed system composed of at least two physical servers, a cloud server providing basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, content delivery network (CDN), and big data and artificial intelligence platform, and the like. The synchronization node device can also refer to a terminal, which can specifically refer to a vehicle terminal, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a screen-equipped speaker, a smart television, a smart watch, and the like, but is not limited thereto.

[0068] The consensus node device can be used to generate blocks, verify blocks, and store verified blocks on the blockchain. The consensus node cluster includes a master node device and a slave node device. The master node device can be a role of the consensus node device in the blockchain. The master node device is mainly used to package transactions to construct a to-be-verified block in a round of consensus, and broadcast the to-be-verified block to other slave node devices in the blockchain network. In other words, the master node device can refer to a consensus node device in the consensus node cluster that is elected to perform block packaging. The slave node device can refer to a consensus node device in the consensus node cluster other than the master node device.

[0069] It should be noted that every k blocks are generated on the blockchain, or every certain time interval, a master node device can be randomly selected from the consensus node devices in the consensus node cluster according to the block height and other information of the blockchain. That is, the selected consensus node device in the consensus node cluster can be referred to as a master node device, and the unselected consensus node device can be referred to as a slave node device. Therefore, any consensus node device in the consensus node cluster can be selected as a master node device, that is, any consensus node device in the consensus node cluster has the functions of a master node device and a slave node device. k can be an integer greater than 1.

[0070] In the present application, one or more transactions in a block on the blockchain correspond to a path, and the path is used to reflect how the transactions reach the blockchain. In the present application, at least two paths of transactions in a block on the blockchain are different. The path can indicate that the transactions reach the blockchain through a sub-chain, or the path can be used to indicate that the transactions reach the blockchain through a subset and a sub-chain. The sub-chain can be used to reflect the transaction category to which the transaction belongs, and the subset can be used to reflect the sub-category under the transaction category to which the transaction belongs. The transaction category to which the transaction belongs can refer to the institution, business category (such as insurance business), and region (such as province) to which the transaction belongs. The sub-category can include the department under the institution, the sub-business type of the business type (renewal business, reimbursement business), and the sub-region (such as county) under the region. For example, in the medical data sharing scenario, the transaction can refer to the medical data of a patient, the sub-chain can be used to reflect the hospital to which the transaction belongs, and the subset under the sub-chain can reflect the department to which the transaction belongs.

[0071] In the present application, the block includes a multi-cross hash chain, and the multi-cross hash chain includes a hash sub-chain for verifying the transactions corresponding to each path in the block. The hash sub-chain includes at least the transaction hash of the transaction on the path and the block metadata hash corresponding to the block metadata.

[0072] In the present application, each synchronization node device can be used to synchronize the block data required by itself from the consensus node device. The block data required by different synchronization node devices can be different.

[0073] It should be noted that the blockchain data processing system of the present application can be applied to the scenarios of Internet of Things (IoT) device data management and clearing, distributed application (DApp) development, supply chain traceability, medical data sharing, legal and compliance records, etc.

[0074] In an Internet of Things (IoT) device data management scenario, the number of devices is large and widely distributed, and each device can only need to synchronize data related to itself. Using a distributed selective data synchronization protocol (DSDSP), IoT devices can act as synchronization node devices. Transactions can refer to data related to the Internet of Things, such as transactions that can include smart home data, livelihood data, city service data, intelligent transportation data (such as real-time traffic data, high-precision map data), etc. Sub-chains can include smart home, smart city, intelligent transportation, and subsets can include livelihood and city services under smart city. Smart home data belongs to smart home, livelihood data belongs to livelihood under smart city, city service data belongs to city service under smart city, and intelligent transportation data belongs to intelligent transportation. Synchronization node devices can only synchronize sub-chains or subsets related to them, such as synchronization node devices for traffic control that can only synchronize transactions in blocks that belong to intelligent transportation (intelligent transportation data), thereby saving bandwidth and storage space. At the same time, the multi-fork tree hash chain proof and verification framework (MHCPVF) can be used to verify the integrity and authenticity of the data synchronized by the consensus node device, ensuring that the data has not been tampered with during transmission.

[0075] In a cross-regional payment and clearing scenario, devices corresponding to financial institutions can act as synchronization node devices, and synchronization node devices can only synchronize transactions related to their own customers. Different sub-chains include data of different financial institutions, and different subsets include data of different departments under different financial institutions. Through the present application, synchronization node devices can only synchronize sub-chains or subsets involving their own customers, improving synchronization efficiency, while ensuring the security and traceability of transactions through the multi-fork tree hash chain. This can greatly speed up the processing speed of cross-regional transactions and reduce operating costs.

[0076] In a distributed application (DApp) development scenario, transactions can refer to different versions or different functions, different application scenarios of distributed applications, different sub-chains can include different distributed applications, and different subsets can include different versions, different functions, and different application scenarios of distributed applications. When developing distributed applications, developers can use the multi-fork tree hash chain structure of the present application to organize distributed applications, so that synchronization node devices that install distributed applications only need to synchronize distributed applications related to themselves. This not only improves the performance of the application, but also provides more personalized services according to user needs.

[0077] In a supply chain management scenario, each participant can only be interested in a specific link of the supply chain. Through the present application, the devices of each party can act as synchronization node devices and only synchronize sub-chains or subsets related to their own business. At the same time, the multi-fork tree hash chain is used to ensure the non-tamperability and traceability of the data, enhancing the transparency and trustworthiness of the supply chain.

[0078] In a medical data sharing scenario, the transaction can refer to patient medical data, different sub-chains include medical data of different medical institutions, and different subsets include medical data of different departments under a medical institution. When sharing medical data between medical institutions, the privacy and security of the data need to be ensured. In the present application, the devices corresponding to the medical institutions act as synchronization node devices, which only synchronize sub-chains or subsets, and at the same time protect the integrity and security of the data through a multi-fork tree hash chain. In this way, the patient's privacy is protected, and the efficiency of data processing is improved.

[0079] In a legal and compliance record scenario, relevant agencies may need to verify whether a specific transaction complies with laws and regulations, and the relevant agencies can include tax agencies, banking agencies, etc., and the transaction can include electronic invoices, loan contracts, mortgage contracts, deposit contracts, etc.; different sub-chains include data to be verified by different agencies, and different subsets include data to be verified by a certain department under an agency. The present application can use devices corresponding to these agencies as synchronization node devices, which only synchronize and verify relevant sub-chains and subsets, and at the same time, through the verification mechanism of the multi-fork tree hash chain, ensure that these transactions are complete and tamper-proof.

[0080] As can be seen, the present application has wide applicability in different scenarios, such as occasions with special requirements for data synchronization efficiency, verification flexibility, and data security. Through the present application, a more efficient, secure, and reliable blockchain solution can be provided for these scenarios. In these scenarios, the present application improves the data processing efficiency and response speed of consensus node devices and synchronization node devices through intelligent scheduling and resource reuse, while reducing operating costs and improving user experience.

[0081] Further, please refer to Figure 2 , which is a flowchart of a blockchain data processing method provided by an embodiment of the present application. As Figure 2 indicated, the method can be performed by a consensus node device in Figure 1 . The method can include the following steps:

[0082] S101, receiving a synchronization request for a blockchain; the synchronization request carries first path information, the first path information is used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicates the path of the corresponding transaction to the blockchain, and there are at least two transactions in the first block whose paths to the blockchain are different.

[0083] In the present application, when the synchronization node device needs to synchronize transactions on the blockchain, the synchronization node device can generate a synchronization request for the blockchain and send it to the consensus node device, and the consensus node device can receive the synchronization request.

[0084] The first block is a block to be synchronized on the blockchain.

[0085] In an embodiment, the synchronization request can include first path information, the first path information can include the block height of the first block and a transaction category, or the first path information can include the block height of the first block, a transaction category and a subcategory under the transaction category; one transaction category corresponds to one subchain in the first block, and a subcategory under the transaction category corresponds to a subset under the subchain in the first block. When the transaction category is included in the first path information, the first path information is used to indicate that the transaction on the first path reaches the blockchain through the first subchain corresponding to the transaction category, i.e., the synchronization request is used to indicate that the transaction belonging to the first subchain in the first block is synchronized to the synchronization node device. When the subcategory under the transaction category is included in the first path information, the first path information is used to indicate that the transaction on the first path reaches the blockchain through the first subchain corresponding to the transaction category and the first subset corresponding to the subcategory, i.e., the synchronization request is used to indicate that the transaction belonging to the first subset under the first subchain in the first block is synchronized to the synchronization node device.

[0086] In an embodiment, the synchronization request can include first path information, the first path information can include the block height of the first block and a transaction category, or the first path information can include the block height of the first block, a transaction category and a subcategory under the transaction category; one transaction category corresponds to one subchain in the first block, and a subcategory under the transaction category corresponds to a subset under the subchain in the first block. When the transaction category is included in the first path information, the first path information is used to indicate that the transaction on the first path reaches the blockchain through the first subchain corresponding to the transaction category, i.e., the synchronization request is used to indicate that the transaction belonging to the first subchain in the first block is synchronized to the synchronization node device. When the subcategory under the transaction category is included in the first path information, the first path information is used to indicate that the transaction on the first path reaches the blockchain through the first subchain corresponding to the transaction category and the first subset corresponding to the subcategory, i.e., the synchronization request is used to indicate that the transaction belonging to the first subset under the first subchain in the first block is synchronized to the synchronization node device.

[0087] S102, according to the first path information, reading a first hash subchain associated with the first path from a first multi-tree hash chain in the first block; the first multi-tree hash chain includes a hash subchain corresponding to each transaction corresponding to each path in the first block.

[0088] In the present application, the consensus node device can read the first hash subchain associated with the first path from the first multi-tree hash chain in the first block according to the first path information, without synchronizing the full amount of the first multi-tree hash chain to the synchronization node device, reducing the consumption of network bandwidth and avoiding wasting the storage space of the synchronization node device.

[0089] The first multi-tree hash chain can be a multi-tree hash chain used to verify the validity of transactions on each path in the first block, and the first hash sub-chain can be a hash sub-chain in the first multi-tree hash chain used to verify the validity of the transaction corresponding to the first path in the first block. The first hash sub-chain at least includes a transaction hash of the transaction corresponding to the first path and a block metadata hash of block metadata of the first block. The block metadata can include one or more of a generation timestamp of the first block, a version of the block chain, a difficulty value, a random number, a block hash of a parent block, and the like, the block metadata hash can be obtained by hashing the block metadata, and the transaction hash can be obtained by hashing the transaction corresponding to the first path.

[0090] It should be noted that the first multi-tree hash chain can be generated according to the hash of the block metadata of the first block and the transaction hash corresponding to the transaction in the first block, or the first multi-tree hash chain can be generated according to the hash of the block metadata of the first block, the transaction hash corresponding to the transaction in the first block, and the multi-tree hash chain in the parent block of the first block. The parent block of the first block can be a block connected to the first block in the block chain and having a block height greater than that of the first block.

[0091] In one embodiment, the first path information indicates that the transaction corresponding to the first path reaches the block chain through the first sub-chain to which the transaction belongs, and the first sub-chain does not include a subset. The first block further includes a transaction corresponding to a second path, and the second path includes a second sub-chain to which the corresponding transaction belongs. The step S102 can include the following steps S121a-S124a:

[0092] S121a, from the first multi-tree hash chain, read the first sub-chain hash corresponding to the first sub-chain, and the first block metadata hash and the first transaction hash connected to the first sub-chain hash; the first sub-chain hash is generated according to the first block metadata hash and the first transaction hash of the transaction corresponding to the first path.

[0093] It should be noted that the first sub-chain hash can be obtained (or concatenated) by hashing the first block metadata hash and the first transaction hash of the transaction corresponding to the first path, or the first sub-chain hash is obtained by hashing the first block metadata hash, the first transaction hash of the transaction corresponding to the first path, and the first sub-chain hash is obtained by concatenating the initial sub-chain hash corresponding to the first sub-chain and the previous sub-chain hash of the first sub-chain. Or, the first sub-chain hash is obtained by concatenating the first block metadata hash, the first transaction hash of the transaction corresponding to the first path, and the previous sub-chain hash of the first sub-chain.

[0094] S122a, reading a second sub-chain hash belonging to the second sub-chain corresponding to the second path from the first multi-tree hash chain; the second sub-chain hash is generated according to the second transaction hash of the transaction corresponding to the second path and the first block metadata hash.

[0095] S123a, reading a first block hash connected with the second sub-chain hash and the first sub-chain hash from the first multi-tree hash chain; the first block hash is generated according to the first sub-chain hash and the second sub-chain hash.

[0096] It should be noted that the first block hash can be obtained by splicing the first sub-chain hash, the second sub-chain hash, and the block hash of the parent block of the first block; or the first block hash is obtained by hashing (or splicing) the first sub-chain hash and the second sub-chain hash.

[0097] S124a, generating the first hash sub-chain according to the second sub-chain hash, the first sub-chain hash, the first transaction hash, the first block metadata hash, the first block hash, and the connection relationship between each two hashes.

[0098] It should be noted that when the second sub-chain does not include a subset, the second sub-chain hash is obtained by splicing the second transaction hash of the transaction corresponding to the second path, the first block metadata hash, and the previous sub-chain hash of the second sub-chain; the previous sub-chain hash of the second sub-chain can refer to the sub-chain hash of the second sub-chain in the parent block of the first block. When the second sub-chain includes a subset, the second sub-chain hash can be obtained by splicing the subset hash corresponding to each subset under the second sub-chain and the previous sub-chain hash of the second sub-chain; the subset hash corresponding to each subset under the second sub-chain can be obtained by splicing the transaction hash corresponding to the transaction under the subset, the first block metadata hash, and the previous subset hash; the previous subset hash can refer to the subset hash of the subset under the second sub-chain in the parent block of the first block.

[0099] In steps S121a-S124a, when the first path information indicates that the transaction corresponding to the first path reaches the blockchain via the first subchain to which it belongs, and the first subchain does not include a subset, the first block also includes a transaction corresponding to the second path, and the second path includes the second subchain to which the corresponding transaction belongs. That is, the synchronization request is used to instruct the synchronization of transactions belonging to the first subchain in the first block to the node device. The number of transactions belonging to the first subchain can be one or more, the number of first and second subchains can be one or more, the second subchain can include multiple subsets, or the second subchain may not include a subset. The consensus node device can generate a first hash subchain based on the second subchain hash, the first subchain hash, the first transaction hash, the first block metadata hash, the first block hash, and the connection between each two hashes.

[0100] For example, Figure 3 As shown, the first block on the blockchain of consensus node device 30a includes block metadata 31a, a first multitree hash chain 32a, a subchain 33a, and a subchain 34a. Subchain 33a includes subsets 311b and 312b. Subset 311b includes transactions 311c and 312c. Subset 312b includes transactions 314c, 314c, and 315c. Subchain 34a may include transactions 311c and 312c. First multitree hash chain 32a may include block hash 311d, subchain hash 312d, subchain hash 313d, subset hash 314d, subset hash 315d, block metadata hash 316d, subchain transaction hash 317d, subset transaction hash 318d, and subset transaction hash 319d. Subset transaction hash 318d may be obtained by hashing transactions 311c and 312c in subset 311b, and subset transaction hash 319d may be obtained by hashing transactions 313c, 314c, and 315c in subset 312b. Subset hash 314d may be the hash corresponding to subset 311b, obtained by concatenating block metadata hash 316d and subset transaction hash 318d. Subset hash 315d may be the hash corresponding to subset 312b, obtained by concatenating block metadata hash 316d and subset transaction hash 319d. Subchain hash 312d corresponds to subchain 33a and is obtained by concatenating subset hash 314d and subset hash 315d. Subchain hash 313d corresponds to subchain 34a and is obtained by concatenating block metadata hash 316d and subchain transaction hash 317d. Subchain transaction hash 317d can be obtained by hashing transactions 311c and 312c under subchain 34a. Block hash 311d is obtained by concatenating subchain hash 312d and subchain hash 313d.

[0101] The sub-chain hash 312d and the sub-chain hash 313d are connected with the block hash 311d respectively, the subset hash 314d and the subset hash 315d are connected with the sub-chain hash 312d respectively, the block metadata hash 316d and the subset transaction hash 318d are connected with the subset hash 314d respectively, and the block metadata hash 316d and the subset transaction hash 319d are connected with the subset hash 315d respectively. The block metadata hash 316d and the sub-chain transaction hash 317d are connected with the sub-chain hash 313d respectively.

[0102] In actual application, when the synchronization node device 35a needs to synchronize the transactions of the sub-chain 34a in the consensus node device 30a, the consensus node device 30a can read the first hash sub-chain 36a from the first multi-cross tree hash chain 42a, the first hash sub-chain 36a including the block hash 311d, the sub-chain hash 312d, the sub-chain hash 313d, the block metadata hash 316d and the sub-chain transaction hash 317d, and the connection relationship between each two hashes in the first hash sub-chain 36a remains consistent with the connection relationship thereof in the first multi-cross tree hash chain 32a.

[0103] It should be noted that when the consensus node device synchronizes the transactions of the sub-chain 34a to the synchronization node device 35a, whether the sub-chain 33a contains a subset or not, the consensus node device only needs to synchronize the sub-chain hash 312d corresponding to the sub-chain 33a to the synchronization node device 35a, and does not need to synchronize the subset hash 314d, the subset hash 315d, the subset transaction hash 318d and the subset transaction hash 319d connected with the sub-chain hash 312d, thereby reducing the network bandwidth efficiency; at the same time, the consensus node device does not need to verify the transactions belonging to the sub-chain 33a, thereby improving the verification efficiency of the transactions.

[0104] In one embodiment, the first path information indicates that the transaction corresponding to the first path reaches the blockchain through the first subset under the first sub-chain to which the transaction belongs and the first sub-chain. The synchronization request is used to indicate that the transactions belonging to the first subset under the first sub-chain are synchronized to the synchronization node device. The first block further includes a transaction corresponding to a second path, and the number of sub-chains of the first block is one. The second path indicates that the transaction corresponding to the second path reaches the blockchain through the second subset under the first sub-chain to which the transaction belongs and the first sub-chain. The step S102 can include the following steps S121b-S123b.

[0105] S121b, reading, from the first multi-tree hash chain, the first sub-chain hash corresponding to the first sub-chain, and the first subset hash and the second subset hash connected with the first sub-chain hash; the first sub-chain hash is generated according to the first subset hash and the second subset hash, the first subset hash is generated according to the first block metadata hash and the first transaction hash corresponding to the transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and the transaction hash corresponding to the transaction belonging to the second subset.

[0106] S122b, reading, from the first multi-tree hash chain, the first block metadata hash and the first transaction hash connected with the first subset hash, and reading the second block hash connected with the first sub-chain hash; the second block hash is generated according to the first sub-chain hash.

[0107] S123b, generating a first hash sub-chain according to the second block hash, the first sub-chain hash, the first subset hash and the second subset hash, the first block metadata hash and the first transaction hash, and the connection relationship between each two hashes.

[0108] In steps S121b-S124b, the first block only includes the transactions of the multiple subsets under the first sub-chain, when the transactions of the first subset need to be synchronized to the synchronization device, only the subset hash and the second subset hash corresponding to the first subset in the first multi-tree hash chain, the transaction hash and the block metadata hash in the first subset, the sub-chain hash and the second block hash corresponding to the first sub-chain need to be synchronized to the synchronization node device, and the full amount of the first multi-tree hash chain does not need to be synchronized to the synchronization node device, thereby reducing the network bandwidth consumption; at the same time, the transactions in the first subset do not need to be verified based on the full amount of the first multi-tree hash chain, thereby improving the verification efficiency.

[0109] Wherein, the first subset can refer to the to-be-synchronized subset of the first sub-chain in the first block, the second subset can refer to the subset in the first sub-chain except the first subset, and the number of the first subset and the number of the second subset can be one or more.

[0110] For example, as shown in FIG. 1, the first block 101 includes a first sub-chain 102 and a second sub-chain 103, the first sub-chain 102 includes a first subset 1021 and a second subset 1022, and the second sub-chain 103 includes a third subset 1031 and a fourth subset 1032. Figure 4As shown, the first block on the blockchain of the consensus node device 40a includes block metadata 41a, a first multi-tree hash chain 42a, and a sub-chain 43a, the sub-chain 43a including a subset 411b and a subset 412b, the subset 411b including a transaction 411c and a transaction 412c, and the subset 412b including a transaction 413c, a transaction 414c, and a transaction 415c. The first multi-tree hash chain 42a can include a block hash 411d, a sub-chain hash 412d, a subset hash 413d, a subset hash 414d, a block metadata hash 415d, a subset transaction hash 416d, and a subset transaction hash 417d. The subset transaction hash 416d can be obtained by hashing the transaction 411c and the transaction 412c in the subset 411b, and the subset transaction hash 417d can be obtained by hashing the transaction 413c, the transaction 414c, and the transaction 415c in the subset 412b. The subset hash 413d can be a hash corresponding to the subset 411b and obtained by concatenating the block metadata hash 415d and the subset transaction hash 416d; and the subset hash 414d can be a hash corresponding to the subset 412b and obtained by concatenating the block metadata hash 415d and the subset transaction hash 417d. The sub-chain hash 412d corresponds to the sub-chain 43a and is obtained by concatenating the subset hash 413d and the subset hash 414d; and the block hash 411d can refer to the sub-chain hash 412d.

[0111] In the actual application, when the synchronization node device 44a needs to synchronize the transactions of the subset 411b under the sub-chain 43a in the consensus node device 40a, the consensus node device 40a can read a first hash sub-chain 45a from the first multi-tree hash chain. The first hash sub-chain 45a includes the block hash 411d, the sub-chain hash 412d, the block metadata hash 415d, the subset transaction hash 416d, and the subset hash 413d and the subset hash 414d, and the connection relationship between each two hashes in the first hash sub-chain 45a is consistent with the connection relationship thereof in the first multi-tree hash chain 42a.

[0112] In the actual application, when the synchronization node device 44a needs to synchronize the transactions of the subset 411b under the sub-chain 43a in the consensus node device 40a, the consensus node device 40a can read a first hash sub-chain 45a from the first multi-tree hash chain. The first hash sub-chain 45a includes the block hash 411d, the sub-chain hash 412d, the block metadata hash 415d, the subset transaction hash 416d, and the subset hash 413d and the subset hash 414d, and the connection relationship between each two hashes in the first hash sub-chain 45a is consistent with the connection relationship thereof in the first multi-tree hash chain 42a.

[0113] In an embodiment, the first path information indicates that the transaction corresponding to the first path reaches the blockchain through a first subset of the first subchain to which the transaction belongs and the first subchain, and the synchronization request is used to indicate that the transaction in the first block belonging to the first subset of the first subchain is synchronized to the synchronization node device. The first block further includes a transaction corresponding to a second path and a transaction corresponding to a third path, the second path indicates that the transaction corresponding to the second path reaches the blockchain through a second subset of the first subchain to which the transaction belongs and the first subchain, and the third path includes a third subchain to which the transaction corresponding to the third path belongs. The step S102 can include the following steps S121c-S123c:

[0114] S121c, from the first multi-tree hash chain, read the first subchain hash corresponding to the first subchain, and the first subset hash and the second subset hash connected with the first subchain hash; the first subset hash is generated according to the first block metadata hash and the first transaction hash corresponding to the transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and the transaction hash corresponding to the transaction belonging to the second subset.

[0115] S122c, from the first multi-tree hash chain, read the first block metadata hash and the first transaction hash connected with the first subset hash, and read the third block hash connected with the first subchain hash and the third subchain hash; the third block hash is generated according to the first subchain hash and the third subchain hash, and the third subchain hash is generated according to the transaction hash corresponding to the transaction corresponding to the third subchain and the first block metadata hash.

[0116] S123c, generate a first hash subchain according to the third block hash, the first subchain hash, the third subchain hash, the first subset hash and the second subset hash, the first block metadata hash and the first transaction hash, and the connection relationship between each two hashes.

[0117] In steps S121c-S124c, the first block includes transactions of multiple subchains, when it is needed to synchronize the transactions of the first subset of the first subchain to the synchronization device, only the first subset hash and the second subset hash corresponding to the first subset in the first multi-tree hash chain, the transaction hash and the block metadata hash of the transaction in the first subset, the subchain hash corresponding to the first subchain, the third subchain hash corresponding to the third subchain and the third block hash need to be synchronized to the synchronization node device, and the full amount of the first multi-tree hash chain does not need to be synchronized to the synchronization node device, thereby reducing the network bandwidth consumption; at the same time, the transactions in the first subset do not need to be verified based on the full amount of the first multi-tree hash chain, thereby improving the verification efficiency.

[0118] The first subset may refer to the subset of the first subchain in the first block to be synchronized, the second subset may refer to the subset of the first subchain excluding the first subset, and the number of first subsets and the number of second subsets may be one or more. The third subchain may refer to the subchain in the first block excluding the first subchain.

[0119] For example, Figure 5 As shown, the first block on the blockchain of consensus node device 50a includes block metadata 51a, a first multitree hash chain 52a, a subchain 53a, and a subchain 54a. Subchain 53a includes subsets 511b and 512b. Subset 511b includes transactions 511c and 512c. Subset 512b includes transactions 514c, 514c, and 515c. Subchain 54a may include transactions 511c and 512c. The first multitree hash chain 52a may include block hash 511d, subchain hash 512d, subchain hash 513d, subset hash 514d, subset hash 515d, block metadata hash 516d, subchain transaction hash 517d, subset transaction hash 518d, and subset transaction hash 519d. Subset transaction hash 518d may be obtained by hashing transactions 511c and 512c in subset 511b, and subset transaction hash 519d may be obtained by hashing transactions 513c, 514c, and 515c in subset 512b. Subset hash 514d may be the hash corresponding to subset 511b, which is the concatenation of block metadata hash 516d and subset transaction hash 518d. Subset hash 515d may be the hash corresponding to subset 512b, which is the concatenation of block metadata hash 516d and subset transaction hash 519d. Subchain hash 512d corresponds to subchain 53a and is obtained by concatenating subset hash 514d and subset hash 515d. Subchain hash 513d corresponds to subchain 54a and is obtained by concatenating block metadata hash 516d and subchain transaction hash 517d. Subchain transaction hash 517d can be obtained by hashing transactions 511c and 512c under subchain 54a. Block hash 511d is obtained by concatenating subchain hash 512d and subchain hash 513d.

[0120] Among them, subchain hash 512d and subchain hash 513d are respectively connected to block hash 511d, subset hash 514d and subset hash 515d are respectively connected to subchain hash 512d, block metadata hash 516d and subset transaction hash 518d are respectively connected to subset hash 514d, block metadata hash 516d and subset transaction hash 519d are respectively connected to subset hash 515d. Block metadata hash 516d and subchain transaction hash 517d are respectively connected to subchain hash 513d.

[0121] In actual applications, when the synchronization node device 55a needs to synchronize transactions of the subset 511b under the subchain 53a in the consensus node device 50a, the consensus node device 50a can read the first hash subchain 56a from the first multitree hash chain 52a. The first hash subchain 56a includes the block hash 511d, the subchain hash 512d, the subchain hash 513d, the block metadata hash 516d, the subchain transaction hash 512d, the subset hash 514d, and the subset hash 515d. The connection relationship between each two hashes in the first hash subchain 56a is consistent with its connection relationship in the first multitree hash chain 52a.

[0122] S103: Read the block metadata of the first block from the first block, and read the transaction corresponding to the first path from the first block according to the first path information.

[0123] In the present application, the consensus node device can read the block metadata of the first block from the first block, and read the transactions corresponding to the first path from the first block based on the first path information. It is not necessary to read all transactions in the first block, and further, it is not necessary to transmit all transactions in the first block, thereby improving the transmission efficiency of transactions.

[0124] In one embodiment, the first path information indicates that transactions corresponding to the first path reach the blockchain via the first subchain to which it belongs, and the first subchain does not include a subset. That is, the synchronization request indicates that transactions belonging to the first subchain should be synchronized to the synchronization node device. Step S103 includes: the consensus node device can read transactions belonging to the first subchain from the first block based on the first path information, and identify the transactions belonging to the first subchain as transactions corresponding to the first path. By organizing transactions into subchains and subsets, a more fine-grained block structure is achieved, allowing the synchronization node device to accurately read the transactions required by the synchronization node device, avoiding the transmission of unnecessary transactions to the synchronization node device and reducing network bandwidth consumption.

[0125] For example, Figure 3In the embodiment, when the synchronization node device 35a needs to synchronize the transactions of the sub-chain 34a in the consensus node device 30a, the consensus node device can read the transactions 316c and 317c belonging to the sub-chain 34a from the first block, and read the block metadata 31a from the first block; so as to synchronize the first hash sub-chain 36a, the block metadata 31a, and the transactions 316c and 317c to the synchronization node device 35a.

[0126] In one embodiment, the first path information indicates that the transactions corresponding to the first path reach the blockchain through the first subset of the first subchain to which it belongs and the first subchain. The synchronization request is used to instruct the synchronization of the transactions in the first block belonging to the first subset under the first subchain to the synchronization node device. The above-mentioned step S103 includes: the consensus node device can read the transactions belonging to the first subset under the first subchain from the first block based on the above-mentioned first path information, and determine the transactions belonging to the first subset under the first subchain as the transactions corresponding to the above-mentioned first path. By organizing transactions in the form of subchains and subsets, a finer-grained block structure is achieved, so that the transactions required by the synchronization node device can be accurately read, avoiding the transmission of unnecessary transactions to the synchronization node device, and reducing network bandwidth consumption.

[0127] For example, Figure 4 As shown, when the synchronization node device 44a needs to synchronize the transactions of the subset 411b under the subchain 43a in the consensus node device 40a, the consensus node device 40a can read the block metadata 41a from the first block, as well as the transactions 411c and 412c belonging to the subchain 43a; so as to synchronize the first hash subchain 45a, the block metadata 41a, and the transactions 411c and 412c to the synchronization node device 44a.

[0128] For example, Figure 5 As shown, when the synchronization node device 55a needs to synchronize the transactions of the subset 511b under the subchain 53a in the consensus node device 50a, the consensus node device 50a can read the block metadata 51a, as well as the transactions 512c and 511c belonging to the subchain 53a from the first block; so as to synchronize the first hash subchain 56a, the block metadata 51a, and the transactions 512c and 511c to the synchronization node device 55a.

[0129] S104. Synchronize the block metadata of the first block, the first hash subchain, and the transactions corresponding to the first path to the synchronization node device. The synchronization node device is used to verify the validity of the transactions corresponding to the first path based on the first hash subchain and the block metadata of the first block, and obtain a verification result. When the verification result indicates that the transactions corresponding to the first path are valid, store the transactions corresponding to the first path.

[0130] In the present application, the consensus node device can synchronize the block metadata of the first block, the transactions corresponding to the first hash sub-chain and the first path, to the synchronization node device. The synchronization node device can verify the validity of the transactions corresponding to the first path according to the block metadata of the first block and the first hash sub-chain, and obtain a verification result. When the verification result indicates that the transactions corresponding to the first path are valid, the transactions corresponding to the first path are stored, and the block metadata of the first block and the first hash sub-chain can also be stored, so that the synchronization node device can store the synchronized transactions in a chain.

[0131] It should be noted that the transactions corresponding to the first path being valid can mean that the transactions corresponding to the first path are complete, i.e., not tampered with; and the transactions corresponding to the first path not being valid can mean that the transactions corresponding to the first path are not complete, i.e., tampered with.

[0132] In one embodiment, when the consensus node device is elected as a master node device, the master node device can generate a new block, and the generation process of the block can include: when the time reaches the packaging time of the block, the master node device can package the transactions in the transaction pool to obtain a to-be-chained block associated with the block chain, the to-be-chained block including block metadata, N transactions, and second path information. The second block also includes the execution results of each transaction in the second block. The second path information is used to indicate that the N transactions respectively arrive at K paths of the block chain, N and K are both positive integers greater than 1, and K is less than or equal to N.

[0133] Further, the master node device can generate hash sub-chains respectively associated with the K paths according to the second block metadata hash corresponding to the block metadata in the to-be-chained block, the transaction hashes respectively corresponding to the N transactions, and the second path information. The hash sub-chain is used to verify the validity of the transactions of the corresponding path. A second multi-tree hash chain can be generated according to the hash sub-chains respectively corresponding to the K paths, the second multi-tree hash chain is added to the to-be-chained block to obtain a second block; the second block is sent to a slave node device corresponding to the block chain; and the slave node device is used to perform consensus processing on the second block to obtain a consensus result. For example, the slave node device can execute the transactions in the second block to obtain execution results, and when the execution results in the second block match the execution results obtained by the slave node device, it is determined that the second block consensus passes, a consensus result indicating that the second block consensus passes is generated, and the consensus result is sent to the master node device. The master node device can receive the consensus result sent by the slave node device, and when the consensus result indicates that the second block consensus passes, the second block is chained to the block chain according to the consensus result.

[0134] In an embodiment, the K paths include a first path and a second path; the second path information indicates that the first path corresponds to a transaction that reaches the blockchain through a first subchain to which the transaction belongs, and the first subchain does not include a subset, and the second path includes a second subchain to which the corresponding transaction belongs; and the master node device generates a hash subchain associated with each of the K paths according to the second block metadata hash corresponding to the block metadata in the to-be-chained block, the transaction hash corresponding to each of the N transactions, and the second path information, including: when the number of transactions corresponding to the first path is one, the master node device can perform a hash operation on the transaction corresponding to the first path to obtain a transaction hash corresponding to the transaction corresponding to the first path; and when the number of transactions corresponding to the first path is more than one, the master node device can splice the hashes of the transactions corresponding to the first path to obtain a transaction hash of the transactions corresponding to the first path.

[0135] Further, the master node device can generate a hash subchain for each path in any of the following two ways. Way one: the master node device can splice the transaction hash of the transaction corresponding to the first path and the second block metadata hash corresponding to the block metadata in the to-be-chained block to obtain a fourth subchain hash corresponding to the first subchain; and taking the second subchain not including a subset as an example, the master node device can splice the transaction hash of the transaction corresponding to the second path and the second block metadata hash to obtain a fifth subchain hash corresponding to the second subchain; and the master node device can splice the fourth subchain hash and the fifth subchain hash to obtain a fourth block hash. The master node device connects the transaction hash of the transaction corresponding to the first path, the second block metadata hash, and the fourth subchain hash, respectively, and connects the fourth subchain hash and the fifth subchain hash to the fourth block hash, respectively, to obtain a second hash subchain corresponding to the first path in the to-be-chained block. The master node device connects the transaction hash of the transaction corresponding to the second path, the second block metadata hash, and the fifth subchain hash, respectively, and connects the fourth subchain hash and the fifth subchain hash to the fourth block hash, respectively, to obtain a hash subchain corresponding to the second path in the to-be-chained block.

[0136] The second mode: the master node device can splice the previous sub-chain hash corresponding to the first sub-chain, the transaction hash of the transaction corresponding to the first path, and the second block metadata hash corresponding to the block metadata in the to-be-chained block to obtain the fourth sub-chain hash corresponding to the first sub-chain. The previous sub-chain hash of the first sub-chain can refer to the sub-chain hash of the first sub-chain in the parent block of the to-be-chained block. Similarly, when the second path does not include a subset, the transaction hash of the transaction corresponding to the second path, the second block metadata hash, and the previous sub-chain hash of the second sub-chain can be spliced to obtain the fifth sub-chain hash corresponding to the second sub-chain. The previous sub-chain hash of the second sub-chain can refer to the sub-chain hash of the second sub-chain in the parent block of the to-be-chained block. The block hash in the parent block of the to-be-chained block, the fourth sub-chain hash, and the fifth sub-chain hash are spliced to generate a fourth block hash. The transaction hash of the transaction corresponding to the first path, the second block metadata hash, the fourth sub-chain hash, and the fifth sub-chain hash are connected to obtain the second hash sub-chain corresponding to the first path in the to-be-chained block. The transaction hash of the transaction corresponding to the second path, the second block metadata hash, the fourth sub-chain hash, and the fifth sub-chain hash are connected to obtain the hash sub-chain corresponding to the second path in the to-be-chained block. The hash sub-chain of each path is generated by combining the sub-chain hash in the parent block, the block hash, and the like, so that the sub-chain hash, the subset hash, and the block hash on the second multi-cross tree hash chain are stored in a complete chain. This is conducive to ensuring the integrity and tamper resistance of the multi-cross tree hash chain, and further ensuring the integrity and tamper resistance of the subset and sub-chain in the block.

[0137] Optionally, the fourth sub-chain hash corresponding to the first sub-chain is generated according to the transaction hash of the transaction corresponding to the first path and the second block metadata hash corresponding to the block metadata in the to-be-chained block, and includes that the master node device can obtain the previous sub-chain hash corresponding to the first sub-chain from the block chain, splice the transaction hash of the transaction corresponding to the first path and the second block metadata hash corresponding to the block metadata in the to-be-chained block to obtain the initial sub-chain hash corresponding to the first sub-chain, and splice the previous sub-chain hash and the initial sub-chain hash corresponding to the first sub-chain to obtain the fourth sub-chain hash corresponding to the first sub-chain. When generating the sub-chain hash corresponding to each sub-chain, the sub-chain hash corresponding to the sub-chain in the parent block is combined, which is conducive to ensuring the integrity and tamper resistance of the multi-cross tree hash chain.

[0138] Optionally, the fourth block hash is generated according to the fourth sub-chain hash and the fifth sub-chain hash, including: obtaining a block hash of a parent block corresponding to the block to be chained from the blockchain; splicing the fourth sub-chain hash and the fifth sub-chain hash to obtain an initial block hash; and splicing the initial block hash and the block hash of the parent block to obtain the fourth block hash. When generating the block hash corresponding to the block, the block hash in the parent block is combined, which is conducive to ensuring the integrity and tamper resistance of the multi-cross tree hash chain.

[0139] For example, as shown in FIG. 6A, the block to be chained on the blockchain of the consensus node device 60a includes block metadata 61a, sub-chain 63a and sub-chain 64a, the sub-chain 63a includes subset 611b and subset 612b, the subset 611b includes transaction 611c and transaction 612c, the subset 612b includes transaction 613c, transaction 614c and transaction 615c, and the sub-chain 64a can include transaction 611c and transaction 612c. Figure 6 The consensus node device 50a can hash the transaction 611c and the transaction 612c in the subset 611b to obtain a subset transaction hash 618d, and hash the transaction 613c, the transaction 614c and the transaction 615c in the subset 612b to obtain a subset transaction hash 619d. The block metadata hash 616d, the subset transaction hash 618d and the previous subset hash 614e are spliced to obtain a subset hash 614d, and the previous subset hash 614e can refer to the subset hash of the subset 611b in the parent block of the block to be chained; the subset hash 614d is the subset hash of the subset 611b in the block to be chained. The block metadata hash 616d, the subset transaction hash 619d and the previous subset hash 615e are spliced to obtain a subset hash 615d, and the subset hash 615d can be the subset hash of the subset 612b in the block to be chained, and the previous subset hash 615e can refer to the subset hash of the subset 612b in the parent block of the block to be chained.

[0140] Furthermore, consensus node device 60a may concatenate subset hash 614d, subset hash 615d, and previous subchain hash 612e to obtain subchain hash 612d; subchain hash 612d is the subchain hash of subchain 63a in the block to be on-chained, and previous subchain hash 612e is the subchain hash of subchain 63a in the parent block of the block to be on-chained. Block metadata hash 616d, subchain transaction hash 617d, and previous subchain hash 613e may be concatenated to obtain subchain hash 613d; subchain hash 613d is the subchain hash of subchain 63a in the block to be on-chained, and previous subchain hash 613e may be the subchain hash of subchain 63a in the parent block of the block to be on-chained. Subchain transaction hash 617d may be obtained by hashing transactions 611c and 612c belonging to subchain 63a in the block to be on-chained. The subchain hash 612d, the subchain hash 613d and the block hash of the parent block are concatenated to obtain the block hash 611d, the subchain hash 612d and the subchain hash 613d are respectively connected to the block hash 611d, the subset hash 614d and the subset hash 615d are respectively connected to the subchain hash 612d, the block metadata hash 616d and the subset transaction hash 618d are respectively connected to the subset hash 614d, the block metadata hash 616d and the subset transaction hash 619d are respectively connected to the subset hash 615d, and the block metadata hash 616d and the subchain transaction hash 617d are respectively connected to the subchain hash 613d to obtain the second multi-tree hash chain 62a.

[0141] In the present application, the transactions in a block are organized in different paths, and a multi-tree hash chain for verifying the transactions corresponding to each path is stored in the block, i.e., the multi-tree hash chain includes hash sub-chains for verifying the transactions corresponding to each path, thereby realizing a fine-grained block structure based on the multi-tree hash chain. When it is necessary to read the transactions on a certain path (first path) in the first block on the blockchain, only the hash sub-chain for verifying the transactions on the first path in the multi-tree hash chain, the block metadata in the first block, and the transactions corresponding to the first path need to be synchronized to the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, thereby reducing unnecessary data transmission and storage, reducing the consumption of network bandwidth, improving synchronization efficiency, and avoiding waste of storage space of the synchronization node device. In addition, the synchronization node device can reduce the consumption of network bandwidth and avoid waste of storage space of the synchronization node device. In addition, the synchronization node device can verify the validity of the transactions corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, in other words, the synchronization node device only needs to verify the transactions of interest (the transactions corresponding to the first path), without the need to verify all transactions in the first block. This fine-grained verification method not only reduces the computational burden, but also improves the efficiency of the verification process, so that even nodes with weak computing power can quickly complete data verification.

[0142] Further, please refer to Figure 7 , which is a flowchart of a blockchain data processing method provided by an embodiment of the present application. As Figure 7 indicated, the method can be performed by a synchronization node device in Figure 1 . The method can include the following steps:

[0143] S201, sending a synchronization request about a blockchain to a consensus node corresponding to the blockchain; the synchronization request carries first path information, the first path information is used to synchronize transactions corresponding to a first path in a first block to the synchronization node device, the first path indicates a path of corresponding transactions reaching the blockchain, and the first block includes at least two transactions reaching the blockchain via different paths.

[0144] In the present application, when the synchronization node device needs to synchronize transactions belonging to a sub-chain or a subset in the first block, a synchronization request about the blockchain can be generated and sent to any consensus node device corresponding to the blockchain.

[0145] S202, receiving block metadata of the first block synchronized by the consensus node, a first hash sub-chain associated with the first path, and a transaction corresponding to the first path; the block metadata of the first block is read from the first block, the first hash sub-chain is read from a first multi-tree hash chain in the first block according to the first path information, the transaction corresponding to the first path is read from the first block according to the first path information, and the first multi-tree hash chain includes a hash sub-chain for verifying each transaction corresponding to the first path in the first block.

[0146] In the present application, the synchronization node device can receive the block metadata of the first block synchronized by the consensus node, the first hash sub-chain associated with the first path, and the transaction corresponding to the first path, to realize a fine-grained transaction synchronization mode, without the need to store transactions irrelevant to the synchronization node device, thereby reducing the storage pressure of the synchronization node device.

[0147] S203, verifying the validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtaining a verification result, and storing the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid.

[0148] In the present application, the synchronization node device can verify the validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtain a verification result, and store the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid, or store the block metadata of the first block, the first hash sub-chain, and the transaction corresponding to the first path, to realize chain storage of the transaction corresponding to the first path, and improve the security of the transaction. At the same time, the synchronization node device does not need to verify all transactions in the first block, thereby improving the efficiency of transaction verification while ensuring the integrity of the transaction of the first path.

[0149] It should be noted that the first hash sub-chain at least includes the transaction hash of the transaction on the first path and the block metadata hash of the block metadata of the first block; when the first hash sub-chain includes the transaction hash of the transaction on the first path and the block metadata hash of the block metadata of the first block, the above step S203 includes: the synchronization node device can hash the transaction corresponding to the first path to obtain the transaction verification hash corresponding to the transaction corresponding to the first path, and hash the block metadata of the first block to obtain the block metadata verification hash. When the transaction verification hash is the same as the first transaction hash in the first hash sub-chain, and the block metadata verification hash is the same as the first block metadata hash in the first hash sub-chain, it indicates that the transaction on the first path is complete, and the transaction on the first path is obtained from the first block. Determine that the transaction corresponding to the first path has validity, and generate a verification result indicating that the transaction corresponding to the first path has validity.

[0150] In one embodiment, the first path information indicates that the transaction corresponding to the first path reaches the blockchain through the first sub-chain to which it belongs, and the first sub-chain does not include a subset, and the first block further includes a transaction corresponding to a second path, and the second path includes a second sub-chain to which the corresponding transaction belongs;

[0151] The first hash sub-chain includes a second sub-chain hash corresponding to the second sub-chain, a first sub-chain hash corresponding to the first sub-chain, a first transaction hash of the transaction corresponding to the first path, a first block metadata hash of the block metadata of the first block, and a first block hash.

[0152] The step S203 includes: the synchronization node device can perform hash operation on the transaction corresponding to the first path to obtain a transaction verification hash corresponding to the transaction corresponding to the first path, and perform hash operation on the block metadata of the first block to obtain a block metadata verification hash. When the transaction verification hash is the same as the first transaction hash in the first hash sub-chain, and the block metadata verification hash is the same as the first block metadata hash in the first hash sub-chain, it is indicated that the transaction on the first path is complete, and the transaction on the first path is obtained from the first block. According to the block metadata verification hash and the transaction verification hash, a sub-chain verification hash of the first sub-chain is generated. According to the sub-chain verification hash, the first sub-chain hash, the second sub-chain hash and the first block hash, the validity of the transaction corresponding to the first path is verified, and a verification result is obtained, that is, whether the transaction of the first path belongs to the first sub-chain is further verified. The transaction on the first path is verified through part of the sub-chain on the multi-way tree hash chain, so as to ensure the integrity of the transaction on the first path and improve the verification efficiency.

[0153] Optionally, the generation of the sub-chain verification hash of the first sub-chain according to the block metadata verification hash and the transaction verification hash includes: the synchronization node device can splice the previous sub-chain hash of the first sub-chain, the block metadata verification hash and the transaction verification hash to obtain the sub-chain verification hash of the first sub-chain.

[0154] The verification of the validity of the transaction corresponding to the first path according to the sub-chain verification hash, the first sub-chain hash, the second sub-chain hash and the first block hash includes: when the sub-chain verification hash is the same as the first sub-chain hash in the first hash sub-chain, it is indicated that the transaction on the first path belongs to the first sub-chain in the first block. The synchronization node device can splice the sub-chain verification hash, the second sub-chain hash in the first hash sub-chain and the block hash of the parent block of the first block to obtain a block verification hash. When the block verification hash is the same as the first block hash in the first hash sub-chain, it is indicated that the transactions in the first block are complete, that is, none of the transactions are tampered with. It is determined that the transaction corresponding to the first path is valid, and a verification result indicating that the transaction corresponding to the first path is valid is generated.

[0155] In the present application, the transactions in a block are organized in different paths, and a Merkle hash chain for verifying the transactions corresponding to each path is stored in the block, i.e., the Merkle hash chain includes hash sub-chains for verifying the transactions corresponding to each path, realizing a fine-grained block structure based on the Merkle hash chain. When reading the transactions on a certain path (first path) in the first block on the blockchain is needed, only the hash sub-chain for verifying the transactions on the first path in the Merkle hash chain, the block metadata in the first block, and the transactions corresponding to the first path need to be synchronized to the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, reducing unnecessary data transmission and storage, reducing the consumption of network bandwidth, improving synchronization efficiency, and avoiding wasting the storage space of the synchronization node device. In addition, the synchronization node device can reduce the consumption of network bandwidth and avoid wasting the storage space of the synchronization node device. In addition, the synchronization node device can verify the validity of the transactions corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, in other words, the synchronization node device only needs to verify the transactions of interest (the transactions corresponding to the first path), without the need to verify the full amount of transactions in the first block. This fine-grained verification method not only reduces the computational burden, but also improves the efficiency of the verification process, so that even nodes with weak computing power can quickly complete data verification.

[0156] In one embodiment, as shown in FIG. 1, a consensus node device can include the following modules: Figure 8

[0157] Network module: responsible for handling communication between various consensus nodes, as well as between the consensus node device and the synchronization node device. The network module can send and receive transactions, blocks, and other important network information. The network module usually includes peer-to-peer network connections, data transmission protocols, and possible network security measures.

[0158] Verification module: responsible for verifying transactions and blocks to ensure they meet the rules and standards of the blockchain network.

[0159] Certificate verification: part of the verification module, responsible for verifying the digital certificate of a transaction or block. This usually involves checking digital signatures to ensure that the data (transaction or block) is sent by a legitimate entity and has not been tampered with during transmission.

[0160] Permission verification: also part of the verification module, responsible for checking whether the entity initiating the transaction has the authority to execute the transaction, which involves access control and identity verification.

[0161] ​Transaction pool module: Responsible for managing and storing transactions that have not yet been packaged into a block. Transactions received by consensus node devices from the network (e.g., terminals) are first placed into the transaction pool, waiting for further processing and confirmation.

[0162] Block synchronization module: Responsible for synchronizing the data of the blockchain with other synchronization node devices (or consensus node devices) to keep the data in each consensus node device up-to-date.

[0163] Fine-grained trusted transaction synchronization module: This is a part of the block synchronization module, specifically responsible for synchronizing a subset or subchain in a block, rather than the entire blockchain (i.e., the entire block). This allows synchronization node devices to synchronize relevant transactions according to their own needs.

[0164] Fine-grained trusted transaction verification module: Used in conjunction with the block synchronization module, this module is responsible for verifying the integrity and correctness of the fine-grained subchain or subset that has been synchronized.

[0165] Scheduling module: Responsible for managing various tasks of the consensus node device, such as transaction processing, block generation, and smart contract execution.

[0166] Block generator: Part of the block scheduling module, responsible for creating new blocks, which selects transactions from the transaction pool, executes them, and packages the results into a block.

[0167] Multi-tree hash chain calculation module: Responsible for calculating the hash of nodes in the multi-tree hash chain to ensure the integrity and tamper resistance of the data.

[0168] Multi-tree hash chain update module: When the data in the blockchain changes, this module is responsible for updating the multi-tree hash chain to reflect these changes.

[0169] Transaction scheduling module: Responsible for assigning transactions to processes in the contract process pool for execution.

[0170] Contract repository: Stores all smart contract code on the blockchain for use by the contract process pool.

[0171] Contract process pool: Manages a series of processes used to execute smart contract code.

[0172] Consensus module: The consensus module is responsible for implementing the consensus mechanism of the blockchain, which ensures that all nodes agree on the state of the blockchain. This module includes the implementation of consensus algorithms and the management of the consensus process.

[0173] Storage module: The storage module is responsible for persistently storing the data of the blockchain.

[0174] Multi-tree hash chain: This is part of the storage module, which stores the structure and data of the multi-tree hash chain to support fast retrieval and verification of data.

[0175] State database: The state database stores the current state of the blockchain, including account balances, the state of smart contracts, etc.

[0176] Block ledger: The block ledger stores all the blocks of the blockchain, including the transaction records and related hash values in each block.

[0177] As can be seen, the above modules together constitute the complete architecture of the consensus node device, each module has a specific function to ensure the normal operation of the blockchain network and the security of data.

[0178] In one embodiment, the various functional modules in 8 can be used to implement the transaction execution process for adding a subset or sub-chain to the multi-tree hash chain of the blockchain, as shown in 9, which can include the following steps: Figure 9

[0179] S301, the administrator packages the sub-chain to be added or the subset corresponding to the subset identifier; that is, the terminal of the administrator corresponding to the blockchain can package the sub-chain identifier of the sub-chain to be added or the subset identifier corresponding to the subset, to obtain the packaged content.

[0180] S302, the administrator signs the above packaged content, and the terminal corresponding to the administrator can use the private key of the administrator to sign the packaged content to obtain the signature of the administrator.

[0181] S303, the administrator sends the above packaged content and signature as a new transaction to the consensus node device; the terminal corresponding to the administrator can send the packaged content and the signature of the administrator as a new transaction to all consensus node devices in the blockchain.

[0182] S304, the network module in the main node device receives the new transaction.

[0183] S305, the certificate verification module verifies the certificate and signature of the above new transaction, and if the verification is passed, go to S307, otherwise go to S306; the certificate verification module in the main node device can use the public key of the administrator and the packaged content to verify the signature, and when the signature verification is passed, it indicates that the new transaction is sent by a legal subject, and the packaged content has not been tampered with in the transmission process, and step S307 is executed; when the signature verification is not passed, it indicates that the new transaction is not sent by a legal subject, or the packaged content is tampered with in the transmission process, then step S306 is executed.

[0184] S306, return the result of the failed signature verification and end.

[0185] ​S307, the authentication module verifies the permission of the above transaction (new transaction), if yes, go to S309, otherwise go to S308; the authentication module in the main node device can authenticate the administrator, when the authentication is passed, that is, the permission verification is passed, it indicates that the terminal corresponding to the administrator has the sending permission for the new transaction, and step S309 is executed; when the authentication is not passed, it indicates that the terminal corresponding to the administrator does not have the sending permission for the new transaction, that is, the permission verification is not passed, and step S308 is executed.

[0186] S308, return the result that the permission verification is not passed, and end.

[0187] S309, the block generator in the block scheduling module obtains the transaction from the transaction pool, prepares to execute the transaction and packs it into a new block; the main node device can store the new transaction into the transaction pool, and wait to be packed, when the time reaches the packing time of the block, the block generator in the block scheduling module of the main node device obtains the transaction from the transaction pool, prepares to execute the transaction and packs it into a new block.

[0188] S310, the block scheduling module schedules the transaction in the block (that is, the to-be-chained block) and the process in the process pool to execute the transaction; the block scheduling module schedules the transaction in the block (that is, the to-be-chained block) and the process in the process pool to execute the transaction, the new transaction in the to-be-chained block is used to indicate the new sub-chain or sub-set.

[0189] S311, when the transaction of the current new sub-chain or sub-set is executed, the contract process obtains the matching system contract from the contract warehouse and starts execution; when the transaction of the new sub-set or sub-chain is executed, the contract process can read the system contract about the new sub-chain or sub-set from the contract warehouse and start execution.

[0190] S312, the system contract queries the multi-way tree hash chain in the storage module.

[0191] S313, the system contract determines whether the path information given in the transaction is correct, if yes, go to S314, otherwise go to S315; for example, whether the path corresponding to the path information in the new transaction exists, if yes, it indicates that the to-be-added sub-chain or sub-set already exists, and step S314 can be executed; if not, it indicates that the to-be-added sub-chain or sub-set has not been created, and step S15 can be executed. Or, whether the end point of the path corresponding to the path information in the new transaction is a child node of the multi-way tree hash chain, if not, it indicates that the to-be-added sub-chain or sub-set already exists, and step S314 can be executed; if yes, it indicates that the to-be-added sub-chain or sub-set has not been created, and step S15 can be executed.

[0192] S314, the system contract returns the result that the path information is incorrect, and goes to S317.

[0193] S315, the system contract updates the multi-tree hash chain according to the path information; the system contract can add a node corresponding to a subset or a node corresponding to a sub-chain on the multi-tree hash chain according to the path information, the node corresponding to the sub-chain can be used to store a sub-chain hash corresponding to the sub-chain, and the node corresponding to the subset can be used to store a subset hash corresponding to the subset.

[0194] S316, the system contract puts the updated multi-tree hash chain into the transaction result.

[0195] S317, after waiting for all transactions to be completed, the scheduling module block generator collects all transaction results and signatures and assembles them into a block.

[0196] S318, the consensus module sends the above block to the slave node for consensus.

[0197] S319, after receiving the to-be-verified block, the slave node also executes the transaction for verification and broadcasts the verification result (i.e. consensus result).

[0198] S320, is the consensus successful? If yes, go to S321, otherwise, end.

[0199] S321, all blockchain nodes (consensus node devices) put the latest multi-tree hash chain into the storage module multi-tree hash chain.

[0200] S322, all consensus node devices put the latest transaction result into the state database.

[0201] S323, the consensus node device appends the latest block to the block ledger.

[0202] In one embodiment, each functional module in 8 can be used to implement the process of block consensus storage based on the multi-tree hash chain, as shown in 9, which can include the following steps: Figure 10

[0203] S401, the user packages and encapsulates the contract name, function name, parameters, and information such as the sub-chain and subset to be called; that is, the contract name, function name, and parameters are transactions to be chained; the user corresponding to the terminal requiring the chained transaction can package and encapsulate the transaction, and the sub-chain identifier of the sub-chain to which the transaction belongs or the subset identifier corresponding to the subset, to obtain the packaged content.

[0204] S402, the user signs the above packaged content; the terminal corresponding to the user can use the private key of the user to sign the packaged content to obtain the signature of the user.

[0205] ​S403, generate a chain request based on the packaged content and the signature, and send the chain request to the consensus node device; the terminal corresponding to the user can generate a chain request based on the packaged content and the signature, and send the chain request to the consensus node device.

[0206] S404, the network module in the master node device receives the chain request.

[0207] S405, the certificate verification module verifies the certificate and the signature of the chain request, and if the verification is passed, go to S407, otherwise go to S406; the certificate verification module in the master node device can use the public key of the user to verify the signature of the chain request, and when the signature verification is passed, it indicates that the user is a legal subject and the packaged content has not been tampered with, and step S407 can be executed; when the signature verification is not passed, it indicates that the user is not a legal subject or the packaged content is tampered with, and step S406 can be executed.

[0208] S406, return the result of the signature verification not passing, and end.

[0209] S407, the authentication module verifies the authority of the chain request, and if the verification is passed, go to S409, otherwise go to S408. The authentication module in the master node device can authenticate the user according to the chain request, and when the authentication is passed, it indicates that the terminal corresponding to the user has the sending authority for the chain request, and step S409 is executed; when the authentication is not passed, it indicates that the terminal corresponding to the user does not have the sending authority for the chain request, i.e. the authority verification is not passed, and step S408 is executed.

[0210] S408, return the result of the authority verification not passing, and end.

[0211] S409, the block generator in the block scheduling module obtains the transaction from the transaction pool, prepares to execute the transaction and packs it into a new block; the master node device can store the transaction in the chain request into the transaction pool, and wait to be packed. When the time reaches the packing time of the block, the block generator in the block scheduling module of the master node device obtains the transaction from the transaction pool, prepares to execute the transaction and packs it into a new block.

[0212] S410, the block scheduling module schedules the transaction in the block and the process in the process pool to execute the transaction.

[0213] S411, after waiting for all the transaction executions to be completed, the block generator in the block scheduling module collects all the transaction results and signatures.

[0214] S412, the block generator in the block scheduling module puts all the transactions into the corresponding transaction table.

[0215] S413, the block generator in the block scheduling module puts the block metadata into the block, i.e. the block to be chained.

[0216] S414, the multi-way tree hash chain updating module in the block scheduling module calculates the hash of the block metadata, i.e. the hash operation on the block metadata of the block to be chained, to obtain the block metadata hash.

[0217] S415, the generator in the block scheduling module calls the multi-way tree hash chain calculation module to construct the multi-way tree hash chain from bottom to top.

[0218] S416, the current node is a leaf node, i.e. a subset transaction hash or a sub-chain transaction hash without a subset? Yes, go to S417, otherwise go to S418, i.e. each node on the multi-way tree hash chain can be traversed in turn.

[0219] S417, calculate the transaction hash of all transactions in the current set (sub-chain or subset). That is, the current node is the node corresponding to the transaction of the subset, and the transaction hash of all transactions of the subset (subset transaction hash) can be obtained; or, the current node is the node corresponding to the transaction of the sub-chain, and the transaction hash of all transactions of the sub-chain (referred to as sub-chain transaction hash) can be obtained, and go to S421.

[0220] S418, the current node is an intermediate subset hash or sub-chain hash? Yes, go to S419, otherwise go to S420.

[0221] S419, splice the hash of the corresponding position of the previous block, the block metadata hash and the lower layer hash, recalculate the hash as the hash of the current node; go to S421; that is, the current node corresponds to the subset hash, which can be calculated according to the transaction hash of all transactions of the subset, the block metadata hash and the subset hash corresponding to the subset in the parent block, to obtain the subset hash of the subset in the current block (i.e. the block to be chained); or, the current node corresponds to the sub-chain hash, and the sub-chain has no subset, which can be calculated according to the lower layer hash of the sub-chain, the block metadata hash and the sub-chain hash corresponding to the sub-chain in the parent block, to obtain the sub-chain hash of the sub-chain in the current block (i.e. the block to be chained).

[0222] S420, the current node is a block hash, splice the hash of the previous block, the sub-chain hash of all sub-chains, and calculate the block hash of the current block. Go to S422.

[0223] S421, calculate the upper node, and go to S416.

[0224] S422, the consensus module sends the above block to the slave node for consensus.

[0225] S423, after the slave node receives the block to be verified, it also performs transaction verification and broadcasts the verification result.

[0226] S424, whether the consensus is successful? Yes, go to S425, otherwise end.

[0227] S425, all consensus node devices put the latest transaction result into the state database and append the latest block to the block ledger.

[0228] In one embodiment, the various functional modules in 8 can be used to implement the process of synchronizing the specified granularity (subset or subchain) of block data in the consensus node device by the synchronization node device, as shown in Figure 11 The process can include the following steps:

[0229] S501, the fine-grained trusted transaction synchronization module in the synchronization module of the synchronization node device detects the block information of the consensus node device.

[0230] S502, the synchronization node device sends a synchronization request to the consensus node device, including the block height and the subchain or subset to be synchronized and its path information; when detecting the block information, the synchronization request including the block height and the subchain or subset to be synchronized and its path information can be sent to the consensus node device.

[0231] S503, the synchronization node device signs the above packaged content, that is, signs the content in the synchronization request, to obtain the signature corresponding to the synchronization node device.

[0232] S504, the synchronization node device sends the above packaged content and signature to the consensus node device, that is, the packaged content is the synchronization request.

[0233] S505, the network module in the consensus node device receives the above synchronization request.

[0234] S506, the certificate verification module verifies the above synchronization request, and if the verification is passed, go to S508, otherwise go to S507.

[0235] S507, return the result of the signature verification not passed, and end.

[0236] S508, the permission verification module verifies the above request, and if the verification is passed, go to S510, otherwise go to S509.

[0237] S509, return the result of the permission verification not passed, and end.

[0238] S510, the block generator multi-fork tree hash chain calculation module in the block scheduling module checks the subchain or subset to be synchronized and its path information.

[0239] S511, the multi-tree hash chain calculation module returns all to-be-verified hash sub-chains in the path process of the block, so that the final verification result is equal to the block hash, and the transaction information of the corresponding subset or sub-chain in the block.

[0240] S512, the consensus node device returns the above fine-grained block to the synchronization node device.

[0241] S513, the synchronization node device acquires the above block and calls the fine-grained trusted transaction verification module in the synchronization module to perform transaction verification.

[0242] S514, the synchronization module sends the transaction of the corresponding subset or sub-chain to the block scheduling module for transaction calculation.

[0243] S515, the block scheduling module compares whether the calculation result is completely consistent with that sent by the consensus node device; if yes, go to S517, otherwise go to S516.

[0244] S516, the block scheduling module returns the result of transaction result verification failure and ends.

[0245] S517, the synchronization module fine-grained trusted transaction verification module reconstructs the multi-tree hash chain and checks whether the block hash is consistent with the received one; if yes, go to S519, otherwise go to S518.

[0246] S518, the synchronization module returns the result of hash verification failure and ends.

[0247] S519, the synchronization module records the results of these transactions in the state database.

[0248] S520, the synchronization module appends the latest block to the block ledger.

[0249] In the present application, the transactions in a block are organized in different paths, and a multi-tree hash chain for verifying the transactions corresponding to each path is stored in the block, i.e. the multi-tree hash chain includes hash sub-chains for verifying the transactions corresponding to each path, realizing a fine-grained block structure based on a multi-tree hash chain. When reading the transactions on a certain path (first path) in the first block on the block chain, only the hash sub-chain for verifying the transactions on the first path in the multi-tree hash chain, the block metadata in the first block and the transactions corresponding to the first path need to be synchronized to the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, reducing unnecessary data transmission and storage, reducing network bandwidth consumption, improving synchronization efficiency and avoiding waste of storage space of the synchronization node device.

[0250] See Figure 12Fig. 1 is a structural schematic diagram of a blockchain data processing apparatus provided by an embodiment of the present application. As shown in Fig. 1, the blockchain data processing apparatus can include: Figure 12

[0251] The receiving module 1211 is configured to receive a synchronization request for a blockchain. The synchronization request carries first path information, the first path information is used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicates a path of corresponding transactions to the blockchain, and paths of at least two transactions in the first block to the blockchain are different.

[0252] The first reading module 1212 is configured to read, according to the first path information, a first hash sub-chain associated with the first path from a first multi-tree hash chain in the first block. The first multi-tree hash chain includes hash sub-chains for verifying transactions corresponding to each path in the first block.

[0253] The second reading module 1213 is configured to read block metadata of the first block from the first block, and read transactions corresponding to the first path from the first block according to the first path information.

[0254] The synchronization module 1214 is configured to synchronize the block metadata of the first block, the first hash sub-chain, and the transactions corresponding to the first path to the synchronization node device. The synchronization node device is configured to verify validity of the transactions corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtain a verification result, and store transactions corresponding to the first path when the verification result indicates that the transactions corresponding to the first path are valid.

[0255] Optionally, the first path information indicates that the transactions corresponding to the first path reach the blockchain through a first sub-chain to which the transactions belong, the first sub-chain does not include a subset, the first block further includes transactions corresponding to a second path, and the second path includes a second sub-chain to which corresponding transactions belong.

[0256] The first reading module 1212 is specifically configured to read, from the first multi-tree hash chain, a first sub-chain hash corresponding to the first sub-chain, and a first block metadata hash and a first transaction hash connected with the first sub-chain hash. The first sub-chain hash is generated according to the first block metadata hash and the first transaction hash of the transactions corresponding to the first path.

[0257] ​read, from the first multi-tree hash chain, a second sub-chain hash corresponding to the second sub-chain pair; the second sub-chain hash is generated according to a second transaction hash of a transaction corresponding to the second path and the first block metadata hash;

[0258] read, from the first multi-tree hash chain, a first block hash connected with the second sub-chain hash and the first sub-chain hash; the first block hash is generated according to the first sub-chain hash and the second sub-chain hash;

[0259] generate the first hash sub-chain according to the second sub-chain hash, the first sub-chain hash, the first transaction hash, the first block metadata hash, the first block hash, and a connection relationship between each two hashes.

[0260] Optionally, the first path information indicates that the transaction corresponding to the first path reaches the blockchain through a first subset under the first sub-chain to which the transaction belongs and the first sub-chain, the first block further includes a transaction corresponding to a second path, and a number of sub-chains of the first block is one, and the second path indicates that the transaction corresponding to the second path reaches the blockchain through a second subset under the first sub-chain to which the transaction belongs and the first sub-chain;

[0261] The first reading module 1212 is specifically configured to read, from the first multi-tree hash chain, a first sub-chain hash corresponding to the first sub-chain, and a first subset hash and a second subset hash connected with the first sub-chain hash; the first sub-chain hash is generated according to the first subset hash and the second subset hash, the first subset hash is generated according to the first block metadata hash and a first transaction hash corresponding to a transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and a transaction hash corresponding to a transaction belonging to the second subset;

[0262] read, from the first multi-tree hash chain, the first block metadata hash and the first transaction hash connected with the first subset hash, and read a second block hash connected with the first sub-chain hash; the second block hash is generated according to the first sub-chain hash;

[0263] generate the first hash sub-chain according to the second block hash, the first sub-chain hash, the first subset hash and the second subset hash, the first block metadata hash and the first transaction hash, and a connection relationship between each two hashes.

[0264] Optionally, the first path information indicates that the transaction corresponding to the first path reaches the blockchain through a first subset of the first subchain to which the transaction belongs and the first subchain, the first block further includes a transaction corresponding to a second path and a transaction corresponding to a third path, the second path indicates that the transaction corresponding to the second path reaches the blockchain through a second subset of the first subchain to which the transaction belongs and the first subchain, and the third path includes a third subchain to which the transaction corresponding to the third path belongs;

[0265] The first reading module 1212 is specifically configured to read, from the first multi-tree hash chain, the first subchain hash corresponding to the first subchain, and the first subset hash and the second subset hash connected with the first subchain hash; the first subchain hash is generated according to the first subset hash and the second subset hash, the first subset hash is generated according to the first block metadata hash and the first transaction hash corresponding to the transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and the transaction hash corresponding to the transaction belonging to the second subset;

[0266] The first reading module 1212 is specifically configured to read, from the first multi-tree hash chain, the first subchain hash corresponding to the first subchain, and the first subset hash and the second subset hash connected with the first subchain hash; the first subchain hash is generated according to the first subset hash and the second subset hash, the first subset hash is generated according to the first block metadata hash and the first transaction hash corresponding to the transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and the transaction hash corresponding to the transaction belonging to the second subset;

[0267] According to the third block hash, the first subchain hash, the third subchain hash, the first subset hash and the second subset hash, the first block metadata hash and the first transaction hash, and the connection relationship between each two hashes, a first hash subchain is generated.

[0268] The second reading module 1213 is specifically configured to read, from the first block, the transaction belonging to the first subchain according to the first path information.

[0269] The transaction belonging to the first subchain is determined as the transaction corresponding to the first path.

[0270] The second reading module 1213 is specifically configured to read, from the first block, the transaction belonging to the first subset under the first subchain according to the first path information.

[0271] The transaction belonging to the first subset under the first subchain is determined as the transaction corresponding to the first path.

[0272] The generating module 1215 is specifically configured to obtain a to-be-chained block associated with the blockchain; the to-be-chained block includes block metadata, N transactions, and second path information; the second path information is used to indicate K paths of the N transactions to the blockchain, and N and K are positive integers greater than 1.

[0273] According to the second block metadata hash corresponding to the block metadata in the to-be-chained block, the transaction hashes corresponding to the N transactions, and the second path information, a hash sub-chain associated with each of the K paths is generated.

[0274] According to the hash sub-chain corresponding to each of the K paths, a second multi-way tree hash chain is generated, the second multi-way tree hash chain is added to the to-be-chained block, and a second block is obtained.

[0275] The second block is sent to a slave node device corresponding to the blockchain; the slave node device is configured to perform consensus processing on the second block to obtain a consensus result.

[0276] The consensus result sent by the slave node device is received, and when the consensus result indicates that the second block passes the consensus, the second block is chained to the blockchain according to the consensus result.

[0277] Optionally, the K paths include a first path and a second path; the first path indicates that a transaction corresponding to the first path reaches the blockchain through a first sub-chain to which the transaction belongs, and the first sub-chain does not include a subset, and the second path includes a second sub-chain to which a corresponding transaction belongs.

[0278] The generating module 1215 is specifically configured to generate a fourth sub-chain hash corresponding to the first sub-chain according to the transaction hash of the transaction corresponding to the first path and the second block metadata hash corresponding to the block metadata in the to-be-chained block.

[0279] According to the transaction hash of the transaction corresponding to the second path and the second block metadata hash, a fifth sub-chain hash corresponding to the second sub-chain is generated.

[0280] According to the fourth sub-chain hash and the fifth sub-chain hash, a fourth block hash is generated.

[0281] The transaction hash of the transaction corresponding to the first path, the second block metadata hash, the fourth sub-chain hash, and the fifth sub-chain hash are connected respectively to obtain a second hash sub-chain corresponding to the first path in the to-be-chained block.

[0282] The generation module 1215 is specifically configured to obtain a previous sub-chain hash corresponding to the first sub-chain from the blockchain.

[0283] The transaction hash of the transaction corresponding to the first path is spliced with the second block metadata hash corresponding to the block metadata in the to-be-chained block to obtain an initial sub-chain hash corresponding to the first sub-chain.

[0284] The previous sub-chain hash and the initial sub-chain hash corresponding to the first sub-chain are spliced to obtain a fourth sub-chain hash corresponding to the first sub-chain.

[0285] The generation module 1215 is specifically configured to obtain a block hash of a parent block corresponding to the to-be-chained block from the blockchain.

[0286] The fourth sub-chain hash and the fifth sub-chain hash are spliced to obtain an initial block hash.

[0287] The initial block hash and the block hash of the parent block are spliced to obtain a fourth block hash.

[0288] In this application, the transactions in a block are organized in the form of different paths, and a Merkle hash chain for verifying the transactions corresponding to each path is stored in the block, that is, the Merkle hash chain includes a hash sub-chain for verifying the transactions corresponding to each path, thereby realizing a fine-grained block structure based on the Merkle hash chain. When reading the transactions on a certain path (the first path) in the first block on the blockchain, only the hash sub-chain for verifying the transactions on the first path in the Merkle hash chain, the block metadata in the first block, and the transactions corresponding to the first path need to be synchronized to the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, thereby reducing unnecessary data transmission and storage, reducing the consumption of network bandwidth, improving synchronization efficiency, and avoiding wasting the storage space of the synchronization node device. In addition, the synchronization node device can reduce the consumption of network bandwidth and avoid wasting the storage space of the synchronization node device. In addition, the synchronization node device can verify the validity of the transactions corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, in other words, the synchronization node device only needs to verify the transactions of interest (the transactions corresponding to the first path), without the need to verify the full amount of transactions in the first block. This fine-grained verification method not only reduces the computational burden, but also improves the efficiency of the verification process, so that even nodes with weak computing power can quickly complete data verification.

[0289] Please refer to Figure 13 is a structural schematic diagram of a blockchain data processing apparatus provided by an embodiment of the present application. As Figure 13 shown, the blockchain data processing apparatus can include:

[0290] The sending module 1311 is configured to send a synchronization request about the blockchain to a consensus node corresponding to the blockchain; the synchronization request carries first path information, the first path information is used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicates a path of corresponding transactions to the blockchain, and paths of at least two transactions in the first block to the blockchain are different;

[0291] The receiving module 1312 is configured to receive block metadata of the first block synchronized by the consensus node, a first hash sub-chain associated with the first path, and transactions corresponding to the first path; the block metadata of the first block is read from the first block, the first hash sub-chain is read from a first multi-tree hash chain in the first block according to the first path information, and the transactions corresponding to the first path are read from the first block according to the first path information, the first multi-tree hash chain includes a hash sub-chain used to verify transactions corresponding to each path in the first block.

[0292] The verification module 1313 is configured to verify validity of the transactions corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, to obtain a verification result, and to store the transactions corresponding to the first path when the verification result indicates that the transactions corresponding to the first path are valid.

[0293] Optionally, the first path information indicates that the transactions corresponding to the first path reach the blockchain through a first sub-chain to which the transactions belong, the first sub-chain does not include a subset, the first block further includes transactions corresponding to a second path, and the second path includes a second sub-chain to which the corresponding transactions belong.

[0294] The first hash sub-chain includes a second sub-chain hash corresponding to the second sub-chain, a first sub-chain hash corresponding to the first sub-chain, a first transaction hash of the transactions corresponding to the first path, a first block metadata hash of the block metadata of the first block, and a first block hash.

[0295] The verification module 1313 is specifically configured to perform a hash operation on the transactions corresponding to the first path to obtain a transaction verification hash corresponding to the transactions corresponding to the first path, and perform a hash operation on the block metadata of the first block to obtain a block metadata verification hash.

[0296] When the transaction verification hash is the same as the first transaction hash in the first hash sub-chain and the block metadata verification hash is the same as the first block metadata hash in the first hash sub-chain, a sub-chain verification hash of the first sub-chain is generated according to the block metadata verification hash and the transaction verification hash;

[0297] According to the sub-chain verification hash, the first sub-chain hash, the second sub-chain hash and the first block hash, the validity of the transaction corresponding to the first path is verified, and a verification result is obtained.

[0298] Optionally, the verification module 1313 is specifically configured to: splice the previous sub-chain hash of the first sub-chain, the block metadata verification hash and the transaction verification hash to obtain the sub-chain verification hash of the first sub-chain.

[0299] According to the sub-chain verification hash, the first sub-chain hash, the second sub-chain hash and the first block hash, the validity of the transaction corresponding to the first path is verified, and a verification result is obtained.

[0300] When the sub-chain verification hash is the same as the first sub-chain hash in the first hash sub-chain, the sub-chain verification hash, the second sub-chain hash in the first hash sub-chain and the block hash of the parent block of the first block are spliced to obtain a block verification hash.

[0301] When the block verification hash is the same as the first block hash in the first hash sub-chain, it is determined that the transaction corresponding to the first path is valid, and a verification result indicating that the transaction corresponding to the first path is valid is generated.

[0302] In the present application, the transactions in a block are organized in different paths, and a multi-tree hash chain for verifying the transactions corresponding to each path is stored in the block, that is, the multi-tree hash chain includes hash sub-chains for verifying the transactions corresponding to each path, thereby realizing a fine-grained block structure based on the multi-tree hash chain. When it is necessary to read the transactions on a certain path (first path) in a first block on the blockchain, only the hash sub-chain for verifying the transactions on the first path in the multi-tree hash chain, the block metadata in the first block, and the transactions corresponding to the first path need to be synchronized to the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, thereby reducing unnecessary data transmission and storage, reducing the consumption of network bandwidth, improving synchronization efficiency, and avoiding waste of storage space of the synchronization node device. In addition, the synchronization node device can reduce the consumption of network bandwidth and avoid waste of storage space of the synchronization node device. In addition, the synchronization node device can verify the validity of the transactions corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, in other words, the synchronization node device only needs to verify the transactions of interest (the transactions corresponding to the first path), without the need to verify all transactions in the first block. This fine-grained verification method not only reduces the computational burden, but also improves the efficiency of the verification process, so that even nodes with weak computing power can quickly complete data verification.

[0303] See Figure 14 is a structural schematic diagram of a computer device provided by an embodiment of the present application. As shown in Figure 14 , the computer device 1000 can be a terminal or a server, and includes a processor 1001, a network interface 1004, and a memory 1005. In addition, the computer device 1000 can further include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to realize the connection and communication between the components. In some embodiments, the user interface 1003 can include a display (DiSPlay), a keyboard (Keyboard), and can further include a standard wired interface, a wireless interface. The network interface 1004 can optionally include a standard wired interface, a wireless interface (such as a WI-FI interface). The memory 1005 can be a high-speed RAM memory or a non-volatile memory (non-volatile MeMory), such as at least one disk storage. The memory 1005 can also be at least one storage device away from the processor 1001. As shown in Figure 14 , the memory 1005, as a computer readable storage medium, can include an operating system, a network communication module, a user interface module, and a computer program.

[0304] InFigure 14 In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface; and the processor 1001 can be used to call a computer program stored in the memory 1005 to implement the method of the present application.

[0305] In the present application, the transactions in a block are organized in different paths, and a multi-tree hash chain for verifying the transactions corresponding to each path is stored in the block, i.e., the multi-tree hash chain includes hash sub-chains for verifying the transactions corresponding to each path, thereby realizing a fine-grained block structure based on a multi-tree hash chain. When reading a transaction on a certain path (first path) in a first block on the blockchain, only the hash sub-chain for verifying the transaction on the first path in the multi-tree hash chain, the block metadata in the first block, and the transaction corresponding to the first path need to be synchronized to the synchronization node device, without the need to synchronize the full amount of the first block to the synchronization node device, thereby reducing unnecessary data transmission and storage, reducing the consumption of network bandwidth, improving synchronization efficiency, and avoiding wasting the storage space of the synchronization node device. In addition, the synchronization node device can reduce the consumption of network bandwidth and avoid wasting the storage space of the synchronization node device. In addition, the synchronization node device can verify the validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, in other words, the synchronization node device only needs to verify the transaction of interest (the transaction corresponding to the first path), without the need to verify all transactions in the first block. This fine-grained verification method not only reduces the computational burden, but also improves the efficiency of the verification process, so that even nodes with weak computing power can quickly complete data verification.

[0306] It should be understood that the computer device described in the embodiments of the present application can perform the description of the above-mentioned blockchain data processing method in the corresponding embodiments of the foregoing, and can also perform the description of the above-mentioned blockchain data processing device in the corresponding embodiments of the foregoing, which will not be repeated here. In addition, the beneficial effects of using the same method will not be described again.

[0307] In the present application, related data collection and processing should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and within the scope of authorization of laws and regulations and the personal information subject, carry out subsequent data use and processing behavior.

[0308] In addition, it is pointed out here that the embodiments of the present application also provide a computer readable storage medium, and the aforementioned computer readable storage medium stores the computer program executed by the aforementioned blockchain data processing apparatus, and the aforementioned computer program includes program instructions, when the aforementioned processor executes the aforementioned program instructions, the aforementioned blockchain data processing method described in the corresponding embodiments of the foregoing can be executed, therefore, this will not be described in detail. In addition, the beneficial effects of using the same method will not be described in detail. For technical details not disclosed in the computer readable storage medium embodiments involved in the present application, please refer to the description of the method embodiments of the present application.

[0309] As an example, the aforementioned program instructions can be deployed on one computer device for execution, or deployed on at least two computer devices in one place for execution, or deployed on at least two computer devices distributed in at least two places and interconnected through a communication network for execution, and the at least two computer devices distributed in at least two places and interconnected through a communication network can constitute a blockchain network.

[0310] The aforementioned computer readable storage medium can be the blockchain data processing apparatus provided by any of the foregoing embodiments or the internal storage unit of the aforementioned computer device, such as the hard disk or internal storage of the computer device. The computer readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, an SMC (SMart Media card), an SD (Secure digital) card, a flash card, etc. equipped on the computer device. Further, the computer readable storage medium can include both the internal storage unit and the external storage device of the computer device. The computer readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer readable storage medium can also be used to temporarily store data that has been output or will be output.

[0311] The terms "first", "second", etc. in the specification and claims and drawings of the embodiments of the present application are used to distinguish different media, not to describe a specific order. In addition, the term "includes" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, device, product or equipment that includes a series of steps or units is not limited to the listed steps or modules, but can optionally include steps or modules that are not listed, or can optionally include other steps or units inherent to the process, method, device, product or equipment.

[0312] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented in whole or in part by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0313] The relevant data collection process in the present application should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and within the scope of authorization of laws and regulations and the personal information subject, carry out subsequent data use and processing behavior.

[0314] The embodiments of the present application also provide a computer program product, including a computer program, which is executed by a processor to realize the description of the above-mentioned blockchain data processing method and decoding method in the corresponding embodiments of the preceding description, therefore, will not be described here. In addition, the beneficial effects of using the same method are not described again. For technical details not disclosed in the embodiments of the computer program product involved in the present application, please refer to the description of the method embodiments of the present application.

[0315] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in the above description in general terms. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0316] The method and related apparatus provided by the embodiments of the present application are described with reference to the method flowchart and / or structural schematic diagram provided by the embodiments of the present application. Each flow and / or block in the method flowchart and / or structural schematic diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable network-connected devices to produce a machine, so that the instructions executed by the computer or other programmable network-connected devices produce a machine that implements the flowchart and / or block diagram in the flowchart and / or block diagram. Figure 1 one flow or multiple flows and / or structural schematic Figure 1apparatus that performs the specific functions. These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable network connection device to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flow Figure 1 flow or flows and / or a schematic diagram of a structure Figure 1 flow or flows and / or a schematic diagram of a structure Figure 1 flow or flows and / or a schematic diagram of a structure

[0317] The above disclosure is merely preferred embodiments of the application and is not to be taken in a limiting sense. Variations and modifications can be made to the application without departing from the spirit thereof as defined in the following claims, and equivalents thereof.

Claims

1. A blockchain data processing method, characterized in that, Comprising: receiving a synchronization request for a blockchain; the synchronization request carries first path information, the first path information is used to synchronize transactions corresponding to a first path in a first block to a synchronization node device, the first path indicates the path of the corresponding transactions to the blockchain, and the paths of at least two transactions in the first block to the blockchain are different; According to the first path information, read the first hash sub-chain associated with the first path from the first multi-tree hash chain in the first block; the first multi-tree hash chain includes a hash sub-chain for verifying the transaction corresponding to each path in the first block, respectively; read the block metadata of the first block from the first block, and read the transaction corresponding to the first path from the first block according to the first path information; synchronize the block metadata of the first block, the first hash sub-chain and the transaction corresponding to the first path to the synchronization node device, the synchronization node device is used to verify the validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, and obtain a verification result, when the verification result indicates that the transaction corresponding to the first path has validity, store the transaction belonging to the first path.

2. The method of claim 1, wherein, The first path information indicates that the transaction corresponding to the first path reaches the blockchain through the first sub-chain to which it belongs, and the first sub-chain does not include a subset, the first block also includes transactions corresponding to a second path, and the second path includes a second sub-chain to which the corresponding transactions belong; According to the first path information, read the first hash sub-chain associated with the first path from the first multi-tree hash chain in the first block, comprising: read the first sub-chain hash corresponding to the first sub-chain, and the first block metadata hash and the first transaction hash connected with the first sub-chain hash from the first multi-tree hash chain; the first sub-chain hash is generated according to the first block metadata hash and the first transaction hash of the transaction corresponding to the first path; read the second sub-chain hash corresponding to the second sub-chain from the first multi-tree hash chain; the second sub-chain hash is generated according to the second transaction hash of the transaction corresponding to the second path and the first block metadata hash; read the first block hash connected with the second sub-chain hash and the first sub-chain hash from the first multi-tree hash chain; the first block hash is generated according to the first sub-chain hash and the second sub-chain hash; generate the first hash sub-chain according to the second sub-chain hash, the first sub-chain hash, the first transaction hash, the first block metadata hash, the first block hash and the connection relationship of every two hashes.

3. The method of claim 1, wherein, The first path information indicates that the transaction corresponding to the first path reaches the blockchain through a first subset of a first subchain to which the transaction belongs and the first subchain, the first block further includes a transaction corresponding to a second path, and the number of subchains of the first block is one, and the second path indicates that the transaction corresponding to the second path reaches the blockchain through a second subset of the first subchain to which the transaction belongs and the first subchain; The first hash subchain associated with the first path is read from the first Merkle hash chain in the first block according to the first path information, including: The first subchain hash corresponding to the first subchain, and the first subset hash and the second subset hash connected with the first subchain hash are read from the first Merkle hash chain; the first subchain hash is generated according to the first subset hash and the second subset hash, the first subset hash is generated according to the first block metadata hash and the first transaction hash corresponding to the transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and the transaction hash corresponding to the transaction belonging to the second subset; The first block metadata hash and the first transaction hash connected with the first subset hash are read from the first Merkle hash chain, and the second block hash connected with the first subchain hash is read; the second block hash is generated according to the first subchain hash; The first hash subchain is generated according to the second block hash, the first subchain hash, the first subset hash and the second subset hash, the first block metadata hash and the first transaction hash, and the connection relationship between each two hashes.

4. The method of claim 1, wherein, The first path information indicates that the transaction corresponding to the first path reaches the blockchain through a first subset of a first subchain to which the transaction belongs and the first subchain, the first block further includes a transaction corresponding to a second path and a transaction corresponding to a third path, the second path indicates that the transaction corresponding to the second path reaches the blockchain through a second subset of the first subchain to which the transaction belongs and the first subchain, and the third path includes a third subchain to which the transaction corresponding to the third path belongs; The first hash subchain associated with the first path is read from the first Merkle hash chain in the first block according to the first path information, including: The first subchain hash corresponding to the first subchain, and the first subset hash and the second subset hash connected with the first subchain hash are read from the first Merkle hash chain; the first subchain hash is generated according to the first subset hash and the second subset hash, the first subset hash is generated according to the first block metadata hash and the first transaction hash corresponding to the transaction belonging to the first subset, and the second subset hash is generated according to the first block metadata hash and the transaction hash corresponding to the transaction belonging to the second subset; read, from the first multi-tree hash chain, the first block metadata hash and the first transaction hash connected with the first subset hash, and read the third block hash connected with the first sub-chain hash and the third sub-chain hash; the third block hash is generated according to the first sub-chain hash and the third sub-chain hash, and the third sub-chain hash is generated according to the transaction hash corresponding to the transaction corresponding to the third sub-chain and the first block metadata hash; generate a first hash sub-chain according to the third block hash, the first sub-chain hash, the third sub-chain hash, the first subset hash and the second subset hash, the first block metadata hash and the first transaction hash, and the connection relationship between each two hashes.

5. The method of claim 2, wherein, The reading, according to the first path information, of the transaction corresponding to the first path from the first block includes: reading, according to the first path information, the transaction belonging to the first sub-chain from the first block; determining the transaction belonging to the first sub-chain as the transaction corresponding to the first path.

6. The method of claim 3 or 4, wherein, The reading, according to the first path information, of the transaction corresponding to the first path from the first block includes: reading, according to the first path information, the transaction belonging to the first subset under the first sub-chain from the first block; determining the transaction belonging to the first subset under the first sub-chain as the transaction corresponding to the first path.

7. The method of claim 1, wherein, The method further includes: obtaining a to-be-chained block associated with the blockchain; the to-be-chained block includes block metadata, N transactions and second path information; the second path information is used to indicate K paths of the N transactions to the blockchain, and N and K are both positive integers greater than 1; generating hash sub-chains respectively associated with the K paths according to a second block metadata hash corresponding to the block metadata in the to-be-chained block, transaction hashes respectively corresponding to the N transactions, and the second path information; generating a second multi-tree hash chain according to the hash sub-chains respectively corresponding to the K paths, adding the second multi-tree hash chain to the to-be-chained block to obtain a second block; sending the second block to a slave node device corresponding to the blockchain; the slave node device is used to perform consensus processing on the second block to obtain a consensus result; receiving the consensus result sent by the slave node device, and when the consensus result indicates that the second block passes the consensus, chaining the second block to the blockchain according to the consensus result.

8. The method of claim 7, wherein, The K paths include a first path and a second path; the first path indicates that the transaction corresponding to the first path reaches the blockchain through the first sub-chain to which the transaction belongs, and the first sub-chain does not include a subset; and the second path includes a second sub-chain to which a corresponding transaction belongs. The generating, according to the second block metadata hash corresponding to the block metadata in the to-be-chained block, the transaction hashes respectively corresponding to the N transactions, and the second path information, of hash sub-chains respectively associated with the K paths includes: generate a fourth sub-chain hash corresponding to the first sub-chain according to a transaction hash of a transaction corresponding to the first path and a second block metadata hash corresponding to block metadata in the block to be chained; generate a fifth sub-chain hash corresponding to the second sub-chain according to a transaction hash of a transaction corresponding to the second path and the second block metadata hash; generate a fourth block hash according to the fourth sub-chain hash and the fifth sub-chain hash; connect the transaction hash of the transaction corresponding to the first path and the second block metadata hash with the fourth sub-chain hash respectively, and connect the fourth sub-chain hash and the fifth sub-chain hash with the fourth block hash respectively, to obtain a second hash sub-chain corresponding to the first path in the block to be chained.

9. The method of claim 8, wherein, The generating a fourth sub-chain hash corresponding to the first sub-chain according to a transaction hash of a transaction corresponding to the first path and a second block metadata hash corresponding to block metadata in the block to be chained comprises: obtaining a previous sub-chain hash corresponding to the first sub-chain from the block chain; splicing the transaction hash of the transaction corresponding to the first path and the second block metadata hash corresponding to the block metadata in the block to be chained to obtain an initial sub-chain hash corresponding to the first sub-chain; splicing the previous sub-chain hash and the initial sub-chain hash corresponding to the first sub-chain to obtain the fourth sub-chain hash corresponding to the first sub-chain.

10. The method of claim 8, wherein, The generating a fourth block hash according to the fourth sub-chain hash and the fifth sub-chain hash comprises: obtaining a block hash of a parent block corresponding to the block to be chained from the block chain; splicing the fourth sub-chain hash and the fifth sub-chain hash to obtain an initial block hash; splicing the initial block hash and the block hash of the parent block to obtain the fourth block hash. 11.A blockchain data processing method, characterized in that, comprises: sending a synchronization request about a block chain to a consensus node corresponding to the block chain; The synchronization request carries first path information, the first path information is used to synchronize transactions corresponding to the first path in the first block to a synchronization node device, the first path indicates a path of the corresponding transactions reaching the block chain, and there are at least two transactions in the first block. The paths of the transactions reaching the block chain are not the same; receiving block metadata of the first block synchronized by the consensus node, a first hash sub-chain associated with the first path, and transactions corresponding to the first path; the block metadata of the first block is read from the first block, the first hash sub-chain is read from a first multi-tree hash chain in the first block according to the first path information, and the transactions corresponding to the first path are read from the first block according to the first path information, the first multi-tree hash chain includes a hash sub-chain used to verify transactions corresponding to each path in the first block respectively. verify validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, to obtain a verification result, and store the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid.

12. The method of claim 11, wherein, The first path information indicates that the transaction corresponding to the first path reaches the blockchain through a first sub-chain to which the transaction belongs, and the first sub-chain does not include a subset, and the first block further includes a transaction corresponding to a second path, and the second path includes a second sub-chain to which the transaction corresponding to the second path belongs; The first hash sub-chain includes a second sub-chain hash corresponding to the second sub-chain, a first sub-chain hash corresponding to the first sub-chain, a first transaction hash of the transaction corresponding to the first path, a first block metadata hash of the block metadata of the first block, and a first block hash; The verifying validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, to obtain a verification result, includes: hashing the transaction corresponding to the first path to obtain a transaction verification hash corresponding to the transaction corresponding to the first path, and hashing the block metadata of the first block to obtain a block metadata verification hash; generating a sub-chain verification hash about the first sub-chain according to the block metadata verification hash and the transaction verification hash when the transaction verification hash is the same as the first transaction hash in the first hash sub-chain, and the block metadata verification hash is the same as the first block metadata hash in the first hash sub-chain; verifying validity of the transaction corresponding to the first path according to the sub-chain verification hash, the first sub-chain hash, the second sub-chain hash and the first block hash, to obtain a verification result.

13. The method of claim 12, wherein, The generating a sub-chain verification hash about the first sub-chain according to the block metadata verification hash and the transaction verification hash includes: splicing a previous sub-chain hash of the first sub-chain, the block metadata verification hash and the transaction verification hash to obtain the sub-chain verification hash about the first sub-chain; The verifying validity of the transaction corresponding to the first path according to the sub-chain verification hash, the first sub-chain hash, the second sub-chain hash and the first block hash, to obtain a verification result, includes: splicing the sub-chain verification hash, the second sub-chain hash in the first hash sub-chain and a block hash of a parent block of the first block to obtain a block verification hash when the sub-chain verification hash is the same as the first sub-chain hash in the first hash sub-chain; determining that the transaction corresponding to the first path is valid when the block verification hash is the same as the first block hash in the first hash sub-chain, and generating a verification result indicating that the transaction corresponding to the first path is valid. 14.A blockchain data processing apparatus, characterized by, includes: a receiving module configured to receive a synchronization request for a blockchain; The synchronization request carries first path information, the first path information is used for synchronizing a transaction corresponding to a first path in a first block to a synchronization node device, the first path indicates a path of the corresponding transaction to the blockchain, and paths of at least two transactions to the blockchain in the first block are different; The first reading module is configured to read, according to the first path information, a first hash sub-chain associated with the first path from a first multi-tree hash chain in the first block; The first multi-tree hash chain includes hash sub-chains for verifying transactions corresponding to each path in the first block, respectively; The second reading module is configured to read block metadata of the first block from the first block, and read the transaction corresponding to the first path from the first block according to the first path information; The synchronization module is configured to synchronize the block metadata of the first block, the first hash sub-chain, and the transaction corresponding to the first path to the synchronization node device, verify validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtain a verification result, and store the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid. 15.A blockchain data processing apparatus, characterized by, The sending module is configured to send a synchronization request about a blockchain to a consensus node corresponding to the blockchain; The synchronization request carries first path information, the first path information is used for synchronizing a transaction corresponding to a first path in a first block to a synchronization node device, the first path indicates a path of the corresponding transaction to the blockchain, and paths of at least two transactions to the blockchain in the first block are different; The receiving module is configured to receive block metadata of the first block, a first hash sub-chain associated with the first path, and a transaction corresponding to the first path synchronized by the consensus node, the block metadata of the first block is read from the first block, the first hash sub-chain is read from a first multi-tree hash chain in the first block according to the first path information, and the transaction corresponding to the first path is read from the first block according to the first path information, the first multi-tree hash chain includes hash sub-chains for verifying transactions corresponding to each path in the first block, respectively; The verification module is configured to verify validity of the transaction corresponding to the first path according to the first hash sub-chain and the block metadata of the first block, obtain a verification result, and store the transaction corresponding to the first path when the verification result indicates that the transaction corresponding to the first path is valid. The processor executes the computer program to implement the steps of the method in any one of claims 1 to 13. 16.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-15. The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 13.

17. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 13.

18. A computer program product comprising a computer program, characterized in that, ​

Images