Data processing method, device and equipment based on block chain and readable storage medium

Abstract

The invention discloses a block chain-based data processing method, apparatus and device, and a readable storage medium. The method comprises the steps of obtaining first transaction data and a transaction type to which the first transaction data belongs; according to the transaction type, determining a target fragment used for caching the first transaction data in N fragments set in a transaction pool of the block chain; the block chain comprises N sub-chains, and the N sub-chains share a transaction pool of the block chain; the N fragments are divided in a transaction pool of the block chain based on N sub-chains, and one fragment corresponds to one sub-chain; and acquiring a node partition corresponding to the first consensus node from M node partitions arranged in the target partition, and caching the first transaction data to the node partition corresponding to the first consensus node. By adopting the method and the device, the cache redundancy of the transaction data can be reduced in the transaction pool cache business, and meanwhile, the reading performance of the transaction data is optimized.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain-based data processing method, device, equipment, and readable storage medium. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. It is mainly used to organize data in chronological order and encrypt it into a ledger to make it impossible to be tampered with or forged. It can also verify, store, and update data.

[0003] The process of writing transaction data into the ledger in the blockchain can be as follows: the client sends the transaction data to the blockchain. After the consensus node in the blockchain receives the transaction data, it will verify the transaction data. After the verification is successful, it will add the transaction data to its own transaction pool and broadcast the transaction data to other consensus nodes in the blockchain. Other consensus nodes will also verify the transaction data and add the transaction data to their own transaction pool after the verification is successful. Each consensus node can obtain the transaction data from the transaction pool, package it, and then write it into the ledger.

[0004] Regarding the above-mentioned method of caching transaction data into the transaction pool, the transaction data cached in each transaction pool is cached sequentially according to the receiving time. There is no regularity between the transaction data and they are mixed, which is not conducive to the reading of transaction data (for example, if you want to read a certain transaction data a, you need to traverse and read the transaction data contained in the transaction pool in sequence to read the transaction data a), and the reading performance of transaction data is poor; in addition, since each transaction data is backed up in all consensus nodes, the transaction data cached by each consensus node is exactly the same, which will greatly increase the cache redundancy of transaction data and waste storage resources. It can be seen that in the transaction data caching business, there is an urgent need for a solution that can reduce the cache redundancy of transaction data and optimize the reading performance of transaction data. Summary of the invention

[0005] The embodiments of the present application provide a blockchain-based data processing method, apparatus, device, and readable storage medium, which can reduce the cache redundancy of transaction data in the transaction pool cache business and optimize the reading performance of transaction data.

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

[0007] Acquire first transaction data and a transaction type to which the first transaction data belongs;

[0008] According to the transaction type, a target shard for caching the first transaction data is determined in the N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer

[0009] Among the M node partitions provided in the target shard, the node partition corresponding to the first consensus node is obtained, and the first transaction data is cached in the node partition corresponding to the first consensus node; M is a positive integer.

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

[0011] An acquisition module, used to acquire the first transaction data and the transaction type to which the first transaction data belongs;

[0012] The shard determination module is used to determine, according to the transaction type, a target shard for caching the first transaction data from among the N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer

[0013] A partition acquisition module, used to acquire the node partition corresponding to the first consensus node from the M node partitions provided in the target shard; M is a positive integer;

[0014] The cache module is used to cache the first transaction data in the node partition corresponding to the first consensus node.

[0015] In one embodiment, after the cache module caches the first transaction data in the node partition corresponding to the first consensus node, the blockchain-based data processing device further includes:

[0016] A node determination module, used to determine a second consensus node for caching the first transaction data among the consensus nodes included in the blockchain;

[0017] The copy sending module is used to send the transaction copy data of the first transaction data to the second consensus node, so that the second consensus node obtains the node partition corresponding to the second consensus node in the M node partitions provided in the target shard, and caches the transaction copy data in the node partition corresponding to the second consensus node.

[0018] In one embodiment, the node determination module determines, among the consensus nodes included in the blockchain, a specific implementation method of a second consensus node for caching the first transaction data, including:

[0019] Get the consensus node cluster contained in the blockchain;

[0020] Count the total number of consensus nodes contained in the consensus node cluster, and perform calculations on the total number of nodes and the specified ratio to obtain the calculation quantity;

[0021] Obtain W consensus nodes in the consensus node cluster according to the number of operations; W is the number of operations;

[0022] W consensus nodes are determined as second consensus nodes for caching the first transaction data.

[0023] In one embodiment, after the cache module caches the first transaction data in the node partition corresponding to the first consensus node, the blockchain-based data processing device further includes:

[0024] A transaction determination module, configured to determine the transaction data stored in the persistent storage component of the first consensus node as second transaction data;

[0025] A file acquisition module, used to acquire a first data file used to represent the first transaction data, and a second data file used to represent the second transaction data;

[0026] A splicing module, used for splicing the first data file with the second data file to obtain a spliced ​​file;

[0027] A strategy determination module, used for determining a storage strategy for the first transaction data based on a file length of the concatenated file;

[0028] The persistent storage module is used to store the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data.

[0029] In one embodiment, the strategy determination module determines a specific implementation of the storage strategy for the first transaction data based on the file length of the concatenated file, including:

[0030] Compare the file length of the concatenated file with the length threshold to obtain a first comparison result;

[0031] If the first comparison result is that the file length of the spliced ​​file is greater than the length threshold, the segment storage strategy is determined as the storage strategy for the first transaction data;

[0032] If the first comparison result is that the file length of the spliced ​​file is less than the length threshold, the entire storage strategy is determined as the storage strategy for the first transaction data.

[0033] In one embodiment, the storage strategy of the target transaction data is a segmented storage strategy;

[0034] The specific implementation method of the persistent storage module storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data includes:

[0035] According to the segment storage strategy, the spliced ​​file is segmented to obtain Q segmented sub-files; one of the Q segmented sub-files contains one or more transaction data; Q is a positive integer;

[0036] Determine a slice sub-file containing target transaction data among the Q slice sub-files as a target slice sub-file;

[0037] Write the target segmentation sub-file to the persistent storage file.

[0038] In one embodiment, the target segmentation subfile contains R transaction data; R is a positive integer;

[0039] The specific implementation method of the persistent storage module writing the target segmentation sub-file to the persistent storage file includes:

[0040] Obtaining a file position of the first transaction data in the target slice sub-file and a file position of the target slice sub-file in the spliced ​​file;

[0041] Combining the file position of the first transaction data in the target slice subfile with the first data file to obtain transaction write data of the first transaction data;

[0042] When the transaction write data of each transaction data in the R transaction data is determined, the transaction write data of each transaction data and the file position of the target slice sub-file in the spliced ​​file are associated and written into the persistent storage file.

[0043] In one embodiment, the storage strategy for the first transaction data is a whole-segment storage strategy;

[0044] The specific implementation method of the persistent storage module storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data includes:

[0045] According to the whole-segment storage strategy, the first data file is written to the persistent storage component.

[0046] In one embodiment, the number of second consensus nodes is at least two;

[0047] After the copy sending module sends the transaction copy data of the first transaction data to the second consensus node, the blockchain-based data processing device further includes:

[0048] A response node acquisition module is used to acquire a response node from at least two second consensus nodes when the message statistics time is reached; the response node refers to the second consensus node that sends a copy storage completion notification to the first consensus node before the message statistics time is reached;

[0049] A node quantity statistics module, used to count a first quantity of response nodes and a second quantity of at least two second consensus nodes;

[0050] a ratio determination module, configured to determine a quantity ratio between a first quantity and a second quantity;

[0051] A notification push module, configured to push a write completion notification to a transaction sending object if the quantity ratio is greater than a ratio threshold; the transaction sending object refers to an object that sends the first transaction data;

[0052] The notification push module is also used to push a write failure notification to the transaction sending object if the quantity ratio is less than the ratio threshold.

[0053] In one embodiment, after the cache module caches the first transaction data in the node partition corresponding to the first consensus node, the blockchain-based data processing device further includes:

[0054] A quantity statistics module, used to count the total number of transactions contained in the node partition corresponding to the first consensus node when receiving the transaction packaging signal;

[0055] A comparison module, used to obtain the block capacity, compare the total number of transactions with the block capacity, and obtain a second comparison result;

[0056] A transaction packaging module, used to determine the packaged transaction data according to the second comparison result;

[0057] The transaction packaging module is also used to package and process the packaged transaction data.

[0058] In one embodiment, the transaction packaging module determines a specific implementation method for packaging the transaction data according to the second comparison result, including:

[0059] If the second comparison result is that the total number of transactions is greater than the block capacity, the first transaction data set is obtained in the node partition corresponding to the first consensus node according to the block capacity, and the first transaction data set is taken as packaged transaction data; the number of transaction data included in the first transaction data set is the block capacity;

[0060] If the second comparison result is that the total number of transactions is less than the block capacity, the quantity difference between the block capacity and the total number of transactions is determined, and the packaged transaction data is determined based on the quantity difference and the transaction data contained in the node partition corresponding to the first consensus node.

[0061] In one embodiment, the transaction packaging module determines a specific implementation method for packaging transaction data based on the transaction data contained in the node partition corresponding to the first consensus node and the quantity difference, including:

[0062] Determine the consensus nodes other than the first consensus node among the consensus nodes included in the blockchain as slave nodes;

[0063] Determine the node partition corresponding to the slave node as the slave partition;

[0064] Obtaining a second transaction data set from the partition according to the quantity difference; the quantity of transaction data included in the second transaction data set is the quantity difference;

[0065] The transaction data contained in the node partition corresponding to the first consensus node and the second transaction data set are jointly determined as packaged transaction data.

[0066] An embodiment of the present application provides a computer device, including: a processor and a memory;

[0067] The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the method in the embodiment of the present application.

[0068] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions. When the program instructions are executed by a processor, the method in the embodiment of the present application is executed.

[0069] In one aspect of the present application, a computer program product is provided, the computer program product comprising a computer program, the computer program being stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device executes the method provided in one aspect of the embodiments of the present application.

[0070] In the embodiment of the present application, by creating different sub-chains in the blockchain, sharing the same transaction pool for each sub-chain, and sharding and partitioning the blockchain transaction pool, the transaction data belonging to the same business type can be cached in different partitions in the same shard, and the transaction data can be cached regularly according to the business type and the received consensus node. One transaction data only needs to be cached in one partition of a shard, and there is no need for repeated caching, which can well reduce the cache redundancy of the transaction data; in addition, this scheme can make the transaction data belonging to the same transaction type be cached in different partitions of the same shard. When reading the transaction data from the transaction pool, it can be read according to the different transaction types and the different received consensus nodes, which can greatly improve the reading efficiency and reading performance of the transaction data. In summary, the present application can reduce the cache redundancy of transaction data in the transaction pool cache business, and at the same time optimize the reading performance of transaction data. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0072] Figure 1 This is a network architecture diagram provided by an embodiment of the present application;

[0073] Figure 2 This is a schematic diagram of a structure for caching transaction data into a transaction pool provided by an embodiment of the present application;

[0074] Figure 3 It is a flowchart of a data processing method based on blockchain provided in an embodiment of the present application;

[0075] Figure 4 It is a schematic diagram of a cache transaction copy provided by an embodiment of the present application;

[0076] Figure 5 It is a schematic diagram of a transaction pool confirmation mechanism provided in an embodiment of the present application;

[0077] Figure 6 This is a schematic diagram of a process for persistently storing transaction data provided by an embodiment of the present application;

[0078] Figure 7 It is a schematic diagram of a data structure for storing transaction data in segments provided by an embodiment of the present application;

[0079] Figure 8This is a flow chart of packaging and uploading transaction data to a chain provided by an embodiment of the present application;

[0080] Fig. 9 This is a schematic diagram of an architecture for node packaging transaction data provided by an embodiment of the present application;

[0081] Fig.10 It is a structural schematic diagram of a blockchain-based data processing device provided in an embodiment of the present application;

[0082] Fig.11 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0083] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0084] The method provided in the embodiment of the present application involves blockchain and other related technologies. For ease of understanding, the following will give priority to blockchain and its related technologies:

[0085] 1. Blockchain: In a narrow sense, blockchain is a chain data structure with blocks as the basic unit. The digital summary is used in the block to verify the transaction history previously obtained, which is suitable for the needs of tamper-proof and scalability in the distributed accounting scenario; in a broad sense, blockchain also refers to the distributed accounting technology implemented by the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, smart contracts, etc. The goal of the blockchain is to realize a distributed data record book, which only allows additions but not deletions. The basic structure of the underlying ledger is a linear linked list. The linked list is composed of "blocks" connected in series, and the hash value of the previous block is recorded in the subsequent block. Whether each block (and the transactions in the block) is legal can be quickly verified by calculating the hash value. If a node in the network proposes to add a new block, it must reach a consensus on the block through the consensus mechanism.

[0086] 2. Blockchain nodes: The blockchain network divides nodes into consensus nodes (also called core nodes), data nodes or light nodes. Among them, the consensus node is responsible for the consensus business of the entire blockchain network; the data node or light node is responsible for synchronizing the ledger information of the consensus node, that is, synchronizing the latest block data. Whether it is a consensus node or a data node (or light node), its internal structure includes network communication components, because the blockchain network is essentially a point-to-point network, and it needs to communicate with other nodes in the blockchain network through related components. The resources and services in the blockchain network are scattered on each node, and the transmission of information and the implementation of services are directly carried out between nodes, without the intervention of intermediate links or centralized servers (third parties).

[0087] 3. Public key and private key: Public key and private key are a key pair (i.e., a public key and a private key) obtained through an algorithm. The public key is the public part of the key pair, and the private key is the non-public part. The public key is usually used to encrypt data, verify digital signatures, etc. This algorithm can ensure that the key pair obtained is unique. When using this key pair, if one of the keys is used to encrypt a piece of data, the other key must be used to decrypt it. For example, if the data is encrypted with the public key, it must be decrypted with the private key. If it is encrypted with the private key, it must also be decrypted with the public key, otherwise the decryption will not be successful.

[0088] 4. Hash value: Also known as information characteristic value or characteristic value, hash value is generated by converting input data of any length into a password and performing fixed output through a hash algorithm. The original input data cannot be retrieved by decrypting the hash value. It is a one-way encryption function. In the blockchain, each block (except the initial block) contains the hash value of the previous block, which is called the parent block of the current block. Hash value is the potential core foundation and the most important aspect of blockchain technology. It preserves the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0089] 5. Smart Contract: It is a computer protocol designed to disseminate, verify or execute contracts in an information-based manner. In the blockchain system, a smart contract (referred to as a contract) is a code that can be understood and executed by each node of the blockchain, which can execute any logic and obtain results. In practical applications, smart contracts are managed and tried through transactions on the blockchain. Each transaction is equivalent to a remote procedure call (RPC) request to the blockchain system. If a smart contract is equivalent to an executable program, the blockchain is equivalent to an operating system that provides an operating environment. The blockchain can contain multiple contracts, which are distinguished by contract accounts (Identity, ID), identification numbers or names. For example, a smart contract can include a governance consensus committee contract, which is mainly used to manage consensus nodes, and can include recording the node status of consensus nodes, dynamically adding consensus nodes, and removing abnormal consensus nodes.

[0090] See also Figure 1 , Figure 1 This is a network architecture diagram provided by an embodiment of the present application. Figure 1 As shown, the network architecture may include a terminal device cluster 10 and a blockchain network, and the blockchain network may include a core node (consensus node) cluster 1000 and a data node or light node cluster 100. The core node cluster 1000 may include at least two core nodes, and the data node cluster 100 may include at least two data nodes. Figure 1 As shown, the core node cluster 1000 may include core node 1000a, core node 1000b, ..., core node 1000n, the data node cluster 100 may specifically include data node 100a, data node 100b, ..., data node 100n, and the terminal device cluster 10 may specifically include terminal device 10a, terminal device 10b, ..., terminal device 10n.

[0091] like Figure 1As shown, terminal device 10a, terminal device 10b, ..., terminal device 10n can respectively establish network connection with data node 100a, data node 100b, ..., data node 100n, so that the terminal device can exchange data with the data node through the network connection; data node 100a, data node 100b, ..., data node 100n can respectively establish network connection with core node 1000a, core node 1000b, ..., core node 1000n, so that the data node can exchange data with the core node through the network connection; data node 100a, data node 100b, ..., data node 100n are connected to each other, so that data nodes can exchange data with each other, and core node 1000a, core node 1000b, ..., core node 1000n are connected to each other, so that core nodes can exchange data with each other.

[0092] Taking the terminal device 10a, the data node 100a and the core node 1000a as an example, the data node 100a can receive a transaction service request sent by the terminal device 10a (the transaction service request carries the ID or name of the smart contract), and then the data node 100a can send the transaction service request to the core node 1000a through the data node cluster 100; the core node 1000a can run the smart contract and execute the transaction service through the smart contract. After obtaining the execution result, the execution result can be stored in the memory pool (such as the transaction pool), and a new block can be generated according to the execution result; then, the core node 1000a can send the newly generated blocks to other core nodes in the blockchain network where it is located according to the node identifiers of other core nodes (i.e., consensus nodes) in the blockchain network, and other core nodes will verify the newly generated blocks (i.e., reach consensus), and add the newly generated blocks to the blockchain stored thereafter (that is, the execution results are stored in the blockchain after the consensus is passed). Among them, each core node in the blockchain network has a corresponding node identifier, and each core node in the blockchain network can store the node identifiers of other core nodes in the blockchain network, so that the generated blocks can be broadcast to other core nodes in the blockchain network according to the node identifiers of other core nodes, so that the data stored on all core nodes in the blockchain network are consistent.

[0093] Among them, Figure 1The terminal device shown can be a desktop terminal or mobile terminal used by the business party that generates transaction information, and can be a smart terminal with data processing functions such as a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart TV, a smart speaker, a desktop computer, a smart watch, a smart car terminal, etc., but is not limited to this. The transaction information (transaction data) generated by the terminal device can be transmitted to the consensus node via a data node or a light node after user authorization, and the consensus node can record the transaction information (transaction data) generated by the terminal device on the blockchain. Any data node in the data node cluster 100 can be implemented with an independent server or a server cluster composed of multiple servers, and any core node in the core node cluster 1000 can be implemented with an independent server or a server cluster composed of multiple servers.

[0094] It can be understood that the transaction business of the terminal device can be understood as transaction data. The main form of storing transaction data in the blockchain is: the transaction data is passed to the consensus node in the form of a baton, and the consensus node then verifies the received transaction data. After the transaction verification is passed, it can be added to its own transaction pool. After adding the transaction data to its own transaction pool, the consensus node can broadcast the transaction data to other consensus nodes in the blockchain, and other consensus nodes will also verify the transaction data, and then verify the transaction data again. After the verification is passed, the transaction data can be added to its own transaction pool. Further, for each consensus node, when receiving a block signal (a block signal can refer to a block signal issued by a timer or a block signal issued by a transaction pool), the consensus node can obtain a batch of transaction data from the transaction pool to package and generate blocks (i.e., package transaction data to generate blocks), and the generated blocks can be added to the blockchain after passing the consensus of each consensus node. In other words, the main form of storing transaction data in the blockchain is: storing in blocks of the blockchain. It should be understood that due to the decentralized and tamper-proof characteristics of blockchain, based on the characteristics of blockchain, the application scenarios of blockchain are constantly expanding. Transaction data of different business types in different business scenarios are expected to be verified, stored and updated through blockchain. The transaction data stored on the blockchain is massive and of mixed types. The transaction pool of each consensus node needs to consume a large amount of storage resources to store massive transaction data, which is a great waste of storage resources. In addition, due to the mixed transaction data types, it is not conducive to the reading of transaction data (for example, if you want to read a certain specified transaction data from the transaction pool, you need to traverse the transaction data in the transaction pool one by one to find the specified transaction data), and the reading performance is very poor.

[0095] In order to improve the reading performance of transaction data in the transaction pool and save storage resources of transaction data, the present application proposes a blockchain transaction pool caching method, through which transaction data can be cached by zone according to the transaction type to which it belongs, which can improve the reading performance of the transaction pool while reducing the storage resources of transaction data.

[0096] Specifically, this application can create different subchains in the blockchain according to different business types, and one subchain serves one business type. For example, taking a certain enterprise as an example, the enterprise uses blockchain to store business data. There are V departments in the enterprise, and each department is responsible for one business. Then the relevant transaction data generated by each department can be classified as one business type. In other words, the transaction data generated by the same department can be classified as the same business type (that is, the type of business that the department is responsible for). It should be understood that the blockchain can be used to store transaction data belonging to different business types, and this solution can create different subchains (sub-blockchains) in the blockchain based on different business types. One subchain can store transaction data of one business type, and these subchains can share the transaction pool of the blockchain (that is, for transaction data added to different subchains, they can be cached in the same transaction pool first). In order to improve the reading performance of the transaction pool, the present application can introduce the concept of "sharding" in the blockchain transaction pool, and divide the transaction pool into multiple shards according to the number of sub-chains. Each sub-chain can correspond to a shard, and data can be isolated between shards. Therefore, transaction data of the same business type can be added to the same shard for caching, while transaction data of different business types will be added to different shards for caching. It can be seen that through the shard division setting in the transaction pool, transaction data of the same business type can be stored in the same shard (that is, in the same area), and transaction data of different business types can be stored in different shards (there is data isolation between different shards, so transaction data of different business types will not be confused). Based on this, when different consensus nodes are packaging transaction data on the chain, they can obtain transaction data of the same business type from each shard to package and generate blocks and add them to the corresponding sub-chain. Then, the transaction data contained in the same block are all of the same business type, and the transaction data stored on a sub-chain are also transaction data of the same business type. When an object (such as a user or an intelligent robot) needs to read certain transaction data (which can be understood as specified transaction data) from the blockchain, it can traverse and query the specified transaction data from the corresponding sub-chain according to the business type to which the specified transaction data belongs and return it to the object.

[0097] In addition, it can be understood that in addition to dividing and setting up multiple shards in the blockchain transaction pool, the present application can also introduce the concept of "partition" in a shard. Specifically, multiple partitions can be divided and set up in a shard according to the number of consensus nodes contained in the blockchain. One consensus node can correspond to one partition. For the transaction data sent to the blockchain by an object (such as a user or an intelligent robot), it can be cached in the corresponding partition in a certain shard according to the consensus node of the received transaction data. For example, assuming that the blockchain transaction pool is divided and set up with 8 shards, and the number of consensus nodes contained in the blockchain is 10, then 10 partitions can be divided and set up in each shard of the blockchain transaction pool. Assuming that for a certain transaction data, the business type to which it belongs is the business type served by shard X, then the transaction data will be cached in shard X. At the same time, the transaction data is received by consensus node A, then the transaction data can be added to the partition corresponding to consensus node A in shard X. It can be seen that by setting up partitions in the shards, the transaction data received by different consensus nodes can be cached in different partitions (there is data isolation between different partitions, so the transaction data received by different consensus nodes will not be confused). Based on this, when different consensus nodes are packaging transaction data on the chain, they can give priority to packaging the transaction data in their corresponding partitions to generate blocks and upload them to the chain. Then, the transaction data contained in the blocks generated by the consensus nodes are basically received and packaged on the chain by the same consensus node. When an object (such as a user or an intelligent robot) needs to read certain transaction data (which can be understood as specified transaction data) from the blockchain, the specified transaction data can be queried from the corresponding sub-chain and the corresponding block according to the business type to which the specified transaction data belongs and the consensus node that receives the transaction data.

[0098] It should be understood that based on the above, by setting up sharding and partitioning in the blockchain transaction pool, when a consensus node receives transaction data, it can cache the transaction data into the corresponding sharding and partitioning. For ease of understanding, here we take the first consensus node (that is, any consensus node in the blockchain) as an example. Assuming that after the first consensus node receives the first transaction data (that is, any transaction data received by the first consensus node), the first consensus node can obtain the business type to which the first transaction data belongs (in this application, the transaction type to which the transaction data belongs is also the business type to which the transaction data belongs, and here it refers to the business type to which the first transaction data belongs. The business type in this application can be set according to the requirements of different business scenarios. For example, the business type may include a resource remittance type, a resource receiving type, a resource exchange type, a resource mortgage type, etc.); according to the transaction type to which the first transaction data belongs, the first consensus node can determine the shard (which can be called the target shard) used to cache the first transaction data from the N (N is a positive integer, usually an integer greater than 1) shards provided in the transaction pool of the blockchain; further, the first consensus node can obtain the node partition corresponding to the first consensus node from the M node partitions (node ​​partition refers to the partition corresponding to the consensus node in the shard) provided in the target shard, and the first consensus node can cache the first transaction data in the node partition corresponding to the first consensus node.

[0099] It can be seen that by creating different sub-chains in the blockchain, sharing the same transaction pool for each sub-chain, and sharding and partitioning the blockchain transaction pool, the transaction data belonging to the same business type can be cached in different partitions in the same shard. According to the business type and the consensus node receiving the transaction data, the transaction data is cached regularly. One transaction data only needs to be stored in one partition of one shard, which can not only improve the reading performance of the transaction data in the transaction pool, but also reduce the storage resources of the transaction data; at the same time, by caching the transaction data regularly, the transaction data belonging to the same business type can be stored in the same sub-chain, and the transaction data received by the same consensus node is also likely to be stored in the same block. Then, when searching for a specified transaction data from the blockchain, it can also be quickly located according to the different business types to which the specified transaction data belongs and the different consensus nodes that receive the specified transaction data. A sub-chain storing the specified transaction data and a batch of blocks that may contain the specified transaction data (these blocks are all generated by the consensus node that receives the specified transaction data) can be found efficiently, so that the present solution can also greatly improve the search efficiency of transaction data.

[0100] It is understandable that the terminal device of the present application may be installed with a target application (ie, an application client). When the application client runs in the terminal device, it may be compatible with the above-mentioned Figure 1 Data is exchanged between other blockchain nodes in the blockchain network shown. Among them, the application client may include multimedia clients (for example, video clients), entertainment clients (for example, game clients), education clients, live broadcast clients and other application clients. Among them, the application client can be an independent client, or it can be an embedded sub-client integrated in a client (for example, an education client and a multimedia client, etc.), which is not limited here. In this application, a blockchain node may refer to a server, which can exchange data with a terminal device through an application in the terminal device (such as a server can receive business data of an application in the terminal device (such as transaction data generated by a user), and the server can process these business data and upload them to the chain). The server here can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and basic cloud computing services such as big data and artificial intelligence platforms.

[0101] It is understandable that the method provided in the embodiment of the present invention can be executed by a computer device, including but not limited to a terminal device or a server (such as a business server). The blockchain node in the embodiment of the present invention can be a computer device.

[0102] It should be noted that in the specific implementation of the present application, data related to user information, user data (such as transaction information and transaction data initiated by users) and the like, all require manual authorization by the user (i.e., user consent) before they can be obtained. In other words, when the above embodiments of the present application are applied to specific products or technologies, the methods and related functions provided by the embodiments of the present application are operated with the permission or consent of the user (the functions provided by the embodiments of the present application can be actively enabled by the user), and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant regions and areas.

[0103] The embodiments of the present application can be applied to various scenarios, including but not limited to gaming scenarios, financial scenarios, cloud technology, artificial intelligence, smart transportation, assisted driving, etc. For ease of understanding, please refer to Figure 2 , Figure 2 Schematic diagram of a structure for caching transaction data into a transaction pool provided by an embodiment of the present application. Figure 2As shown, in the transaction pool of the blockchain, the present application can be divided into different shards (a shard can be understood as a cache space or cache area in the transaction pool), wherein the present application can be divided into shards according to the different business types that the blockchain is responsible for. For example, the blockchain can be used to cache transaction data of resource export type, resource reception type and resource exchange type, then different subchains can be created in the blockchain to store transaction data of different business types. For example, subchain 1, subchain 2 and subchain 3 can be created in the blockchain, subchain 1 can be used to store transaction data of resource export type, subchain 2 can be used to store transaction data of resource reception type, and subchain 3 can be used to store transaction data of resource exchange type. For each subchain, the corresponding shards can be divided and set in the transaction pool of the blockchain to cache the transaction data to be added to the subchain, that is, each shard can be responsible for caching transaction data of different business types. For example, Shard-A, Shard-B, and Shard-C can be created in the transaction pool of the blockchain, where Shard-A can be used to cache transaction data to be added to sub-chain 1. When the packaged transaction data is added to sub-chain 1, the transaction data can be obtained from Shard-A for packaging and chaining; Shard-B can be used to cache transaction data to be added to sub-chain 2. When the packaged transaction data is added to sub-chain 2, the transaction data can be obtained from Shard-B for packaging and chaining; Shard-C can be used to cache transaction data to be added to sub-chain 3. When the packaged transaction data is added to sub-chain 3, the transaction data can be obtained from Shard-C for packaging and chaining.

[0104] It should be noted that in some blockchain scenarios, when creating a subchain in the blockchain, the application can determine the number of subchains created according to the number of consensus nodes. One subchain can correspond to one consensus node, so multiple subchains can be obtained. For example, the blockchain contains consensus nodes 1, 2, and 3. Then the application can create a subchain 1 based on consensus node 1, a subchain 2 based on consensus node 2, and a subchain 3 based on consensus node 3. Further, the business type that the subchain 1 is responsible for processing can be specified as business type 1, the business type that the subchain 2 is responsible for processing can be specified as business type 2, and the business type that the subchain 3 is responsible for processing can be specified as business type 3. In other words, in addition to creating different subchains according to the business type that the blockchain is responsible for, the application can also create multiple subchains according to the number of consensus nodes, and specify the business type of the transaction data that it is responsible for maintaining for each subchain, thereby allowing each subchain to maintain transaction data of different business types.

[0105] like Figure 2As shown, assuming that there are consensus nodes-a and consensus nodes-b in the blockchain... then a corresponding subchain can be created for each consensus node in the blockchain, for example, subchain 1 can be created for consensus node-a, and subchain 2 can be created for consensus node-b... The corresponding business type can be specified for each subchain configuration. Accordingly, in the transaction pool of the blockchain, these subchains can share this transaction pool, and the embodiment of the present application can set different shards in the transaction pool based on different subchain divisions. For example, shard-A can be set for subchain 1, and shard-B can be set for subchain 2... Shard-A can be used to cache the relevant transaction data of subchain 1, and shard-B can be used to cache the relevant transaction data of subchain 2... Based on this, each shard in the transaction pool can cache transaction data of different business types.

[0106] It is understandable that the present application can further subdivide each shard into different partitions (a partition can be understood as a portion of the cache space or cache area in the shard) according to the different consensus nodes in each shard, and each partition is used to cache the transaction data received by the corresponding consensus node. Figure 2 As shown, in shard-A, partition-A1 and partition-A2 can be divided and set... Partition-A1 is used to cache the transaction data received by consensus node-a, and partition-A2 is used to cache the transaction data received by consensus node-b... In shard-B, partition-B1 and partition-B2 can be divided and set... Partition-B1 is used to cache the transaction data received by consensus node-a, and partition-B2 is used to cache the transaction data received by consensus node-b... For different objects (such as Figure 2 The transaction data sent by the objects a1, a2, and a3 shown can be cached in the corresponding partitions in the corresponding shards in the transaction pool based on the different business types to which the transaction data belongs and the different consensus nodes that receive the transaction data.

[0107] For example, taking object a1 sending transaction data K1 as an example, the business type to which transaction data K1 belongs is the business type maintained by subchain 1, then the transaction data K1 should be cached in shard-A in the transaction pool. Since the consensus node that receives the transaction data in the blockchain is consensus node-a, the transaction data K1 will be cached in partition-A1 of shard-A.

[0108] It should be understood that by creating different sub-chains in the blockchain, sharing the same transaction pool among the sub-chains, and sharding and partitioning the blockchain transaction pool, transaction data belonging to the same business type can be cached in different partitions in the same shard. Transaction data can be cached regularly according to the business type and the receiving consensus node. One transaction data only needs to be stored in one partition of one shard, which can not only improve the reading performance of transaction data in the transaction pool, but also reduce the storage resources of transaction data.

[0109] For ease of understanding, the data processing method provided by the embodiment of the present application will be described in detail below with reference to the accompanying drawings. Figure 3 , Figure 3 This is a flowchart of a data processing method based on blockchain provided by an embodiment of the present application. The process can be executed by a computer device, which can be Figure 1 Any core node (consensus node) shown in FIG. 1 is executed, and the consensus node can be called the first consensus node. Figure 3 As shown, the process may include at least the following steps S101 to S103:

[0110] Step S101, obtaining first transaction data and the transaction type to which the first transaction data belongs.

[0111] In this application, transaction data can be sent to the blockchain by an object (user or intelligent robot), and the transaction data will be transmitted to the consensus node through the propagation of data nodes, and the first transaction data here can refer to any transaction data received by the first consensus node. After receiving the first transaction data, the first consensus node can obtain the transaction type to which the first transaction data belongs, and determine the cache location of the first transaction data based on the transaction type to which the first transaction data belongs. Among them, the transaction type of transaction data is equivalent to the business type to which the transaction data belongs, and the business type can be configured and determined based on different business scenarios. For example, in a financial scenario, the business type may include resource remittance type, resource exchange type, resource mortgage type, etc.; in a game scenario, the business type may include the type of update of the attributes of a virtual character (such as appearance, character attack power, etc.), account recharge type, etc. Examples will not be given one by one here.

[0112] Step S102, according to the transaction type, determine the target shard for caching the first transaction data from the N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer.

[0113] In this application, in order to improve the writing performance and reading performance of transaction data, N (N is a positive integer, usually an integer greater than 1) subchains can be created in the blockchain to store transaction data of different transaction types (business types). For example, taking the business types including business type 1, business type 2 and business type 3 as an example, subchain 1 can store transaction data of business type 1, subchain 2 can store transaction data of business type 2, and subchain 3 can store transaction data of business type 3. It should be understood that by creating different subchains, transaction data of different business types can be stored in the same location for easy writing and reading. For the creation of subchains, it can be created based on the number of consensus nodes in the blockchain (specifically, one can be created for each consensus node, so that the number of subchains created is the same as the number of consensus nodes, and further, each subchain can be specified to configure the business type it is responsible for maintaining, so that each subchain can maintain and store transaction data of different business types); it can also be directly based on the business type served by the blockchain as a whole to create a subchain. For example, if there are 4 business types maintained by the blockchain, then 4 subchains can be created in the blockchain. This application does not limit the method for determining the number of sub-chains.

[0114] It should be understood that for transaction data sent to the blockchain but not yet on the chain, the consensus node will first cache it in the transaction pool of the blockchain. Similarly, for transaction data to be chained to each sub-chain, the consensus node will cache it in the transaction pool of the blockchain after receiving it. The sub-chains in this application will share the transaction pool of the blockchain. The business types of transaction data maintained by each sub-chain are not the same. If all of them are cached in the transaction pool, the transaction data will be very messy. When the consensus node packages the transaction data and adds it to the sub-chain, it also needs to traverse the transaction pool to find the transaction data belonging to a certain sub-chain, and then package it on the chain, which is time-consuming and labor-intensive, and the reading performance of the transaction pool is not good. In order to improve the reading performance of the transaction pool, this application can divide the transaction pool according to the number of sub-chains, so as to obtain different cache areas. These cache areas can be understood as shards in the transaction pool. A shard can be used to cache the transaction data to be chained (i.e., the transaction data to be added to the sub-chain) of a sub-chain. By setting up shard division in the transaction pool, after receiving the transaction data, the consensus node can cache it in different shards in the transaction pool according to the business type (transaction type) to which the transaction data belongs. In this way, transaction data of the same business type can be cached in the same shard. When the transaction data is packaged and uploaded to the chain, the corresponding shard can be located according to the business type to which the transaction data belongs, and then the transaction data of the same business type can be obtained from the shard and packaged and added to the corresponding sub-chain.

[0115] That is to say, after obtaining the first transaction data, the first consensus node in the present application can determine the shard used to cache the first transaction data from the N shards provided in the transaction pool according to the transaction type to which the first transaction data belongs (which can be called the target shard, and the business type of the transaction data maintained by the target shard is the same as the transaction type to which the first transaction data belongs).

[0116] Step S103, obtaining the node partition corresponding to the first consensus node from the M node partitions provided in the target shard, and caching the first transaction data into the node partition corresponding to the first consensus node; M is a positive integer.

[0117] In this application, in order to further improve the regularity of transaction data caching, this application can also set different partitions in each shard according to the number of consensus nodes (each partition can be called a node partition). For transaction data sent to the blockchain, it can be cached in different partitions in different shards according to the different transaction types and the different consensus nodes received. Based on this, after receiving the first transaction data, the first consensus node can first determine the target shard among the N shards according to the transaction type to which the first transaction data belongs, and then obtain the node partition corresponding to the first consensus node in the target shard, and the first transaction data can be cached in the node partition of the target shard.

[0118] Further, it should be understood that the transaction data caching method of caching transaction data in a partition of a shard can well reduce the redundancy of transaction data caching, and the write performance of transaction data sent to the transaction pool is high. However, when an exception occurs in the consensus node (such as a node restart), data loss is likely to occur. Therefore, based on this, the present application can determine the consensus node that receives the transaction data as the master node, and the remaining consensus nodes that have not received the transaction data can be used as slave nodes. For the node partition corresponding to the master node in the shard, it can be called the master partition, and for the node partition corresponding to the slave node in the shard, it can be called the slave partition. Then, after the master node receives a certain transaction data, after caching it to the corresponding shard and the corresponding node partition, the master node can send the copy data of this transaction data to other slave nodes, and other slave nodes can cache the copy data in their own node partitions, so that the same transaction data can be cached at different consensus nodes. Then, in the case of an exception in the master node, since the corresponding transaction data is also cached at other consensus nodes, data loss will not be caused.

[0119] Specifically, taking the first consensus node caching the first transaction data as an example, the first consensus node can be used as the master node. After the first consensus node caches the first transaction data in the node partition corresponding to the first consensus node, the first consensus node can also send the copy data of the first transaction data (which can be called transaction copy data) to other consensus nodes, wherein, before sending the copy data of the first transaction data, the first consensus node can select some consensus nodes to cache the copy data (that is, there is no need to send the copy data to all other consensus nodes), thereby avoiding all consensus nodes from caching the same transaction data and reducing the redundancy of transaction data cache. Specifically, after caching the first transaction data in the node partition corresponding to the first consensus node, the first consensus node can determine the second consensus node for caching the first transaction data among the consensus nodes included in the blockchain; further, the first consensus node can send the transaction copy data of the first transaction data to the second consensus node, so that the second consensus node obtains the node partition corresponding to the second consensus node in the M node partitions provided in the target shard, and caches the transaction copy data in the node partition corresponding to the second consensus node.

[0120] Among them, the specific method for determining the second consensus node for caching the first transaction data among the consensus nodes included in the blockchain can be: a consensus node cluster included in the blockchain can be obtained; then, the total number of consensus nodes included in the consensus node cluster can be counted, and the total number of nodes can be processed with a specified ratio to obtain the number of operations; further, W consensus nodes can be obtained in the consensus node cluster according to the number of operations; wherein W is the number of operations; further, the W consensus nodes can be determined as the second consensus nodes for caching the first transaction data.

[0121] It can be understood that the consensus node cluster here may refer to a cluster other than the first consensus node (that is, the consensus node cluster does not include the first consensus node), and the specified ratio may be an artificially determined ratio (such as 2 / 3, 8 / 10, etc.). By multiplying the total number of consensus node clusters by the specified ratio, the number of consensus nodes used to cache the transaction copy data of the first transaction data can be obtained. Subsequently, W consensus nodes can be randomly selected in the consensus node cluster according to the number of operations as the second consensus nodes to cache the transaction copy data of the first transaction data.

[0122] For easier understanding, please also refer to Figure 4 , Figure 4 Schematic diagram of a cache transaction copy provided by an embodiment of the present application. Figure 4As shown, in the shard-A of the transaction pool, there may be a node partition (partition-1) corresponding to consensus node-a, a node partition (partition-2) corresponding to consensus node-b, a node partition (partition-3) corresponding to consensus node-c, and a node partition (partition-4) corresponding to consensus node-d. After the transaction data received by consensus node-a is cached in partition-1 in shard-A, consensus node-a can use consensus node b and consensus node c as nodes for caching copies of the transaction data, and consensus node-a can send copies of the transaction data to consensus node-b and consensus node-c (as shown in the figure, consensus node-b and consensus node-c will both receive the transaction data in partition-1 in shard-A). Similarly, after consensus node-b receives transaction data and caches it in partition-2 in shard-A, consensus node-b can use consensus node c and consensus node d as nodes that cache copies of the transaction data, and consensus node-b can send copies of the transaction data to consensus node-c and consensus node-d (as shown in the figure, consensus node-c and consensus node-d will both receive the transaction data in partition-2 in shard-A). Similarly, after consensus node-d receives transaction data and caches it in partition-4 in shard-A, consensus node-d can use consensus node a and consensus node b as nodes that cache copies of the transaction data, and consensus node-d can send copies of the transaction data to consensus node-a and consensus node-b (as shown in the figure, consensus node-a and consensus node-b will both receive the transaction data in partition-4 in shard-A).

[0123] It should be understood that by configuring the number of cached transaction data copies, the same transaction data can be cached at different nodes, which can prevent data loss due to abnormalities in the master node. It can also avoid all consensus nodes receiving and caching all transaction data, thereby greatly reducing the amount of data transmitted between nodes and reducing the redundancy of transaction data cache.

[0124] After the master node sends a copy of the transaction data to other consensus nodes, the master node can wait for each consensus node to return a confirmation notification (for confirming that the copy data has been received and cached) within a certain period of time, and the master node can push a write completion notification for the transaction data to the transaction sending object (i.e., the object sending the transaction) after receiving the confirmation notification sent by a certain number of consensus nodes, to notify the object that the transaction data has been successfully written into the transaction pool. Taking the example of the first consensus node sending the transaction copy data of the first transaction data to the second consensus node, assuming that the number of second consensus nodes is at least two, then after sending the transaction copy data of the first transaction data to the second consensus node, the first consensus node can obtain a response node from at least two second consensus nodes when the message statistics time is reached (this application can determine the message statistics time based on the sending time of the transaction copy data and the preset waiting time period (such as 5s, 10s, etc.), for example, the sending time of the transaction copy data and the waiting time period can be summed and processed, and the result of the operation can be used as the message statistics time); wherein the response node refers to the response node that reaches the message statistics time. Before the time, the second consensus node sends a copy storage completion notification (the copy storage completion notification is a confirmation notification, which is used to notify the first consensus node that the transaction copy data has been received and cached) to the first consensus node; further, the first number of responding nodes and the second number of at least two second consensus nodes can be counted; the quantity ratio between the first number and the second number can be determined; if the quantity ratio is greater than a ratio threshold (the ratio threshold can be determined by the first consensus node), the first consensus node can push a write completion notification to the transaction sending object; wherein the transaction sending object refers to the object that sends the first transaction data; and if the quantity ratio is less than the ratio threshold, a write failure notification can be pushed to the transaction sending object.

[0125] It should be understood that the transaction confirmation mechanism that receives confirmation notifications from a certain number of second consensus nodes and then pushes a write completion notification to the transaction sending object can greatly improve the reliability of transaction data transmission. Assuming that after the transaction sending object sends the transaction data, it confirms that the transaction is written without waiting for the response of any second consensus node, then this confirmation mechanism can send transaction data at a relatively high speed, thereby achieving a very high throughput, but if a write failure occurs, the transaction data will be lost; and if the transaction sending object sends the transaction data, the master node pushes a write completion notification to the transaction sending object after the cache is successful, then the transaction sending object will confirm that the transaction is written. This confirmation mechanism will make the performance of sending to the transaction pool higher, but once the master node itself is abnormal, data loss may occur; and if among other consensus nodes, the master node receives the confirmation notification returned by some second consensus nodes (that is, the consensus nodes to which the transaction copy data is sent, which can be understood as copy nodes), and then pushes the transaction write completion notification to the transaction sending object, then this confirmation mechanism can well ensure the reliability and security of transaction data writing, and can ensure that more than one node receives the transaction data and caches it. In the present application, all three confirmation mechanisms mentioned above can be adopted, but the third confirmation mechanism can be preferentially adopted as the confirmation mechanism for determining whether a transaction is written in the present application.

[0126] For easier understanding, please also refer to Figure 5 , Figure 5 Schematic diagram of a transaction pool confirmation mechanism provided by an embodiment of the present application. Figure 5 The confirmation mechanism shown is a scenario example using the third confirmation mechanism as an example. Figure 5 As shown, it is assumed that the consensus nodes in the transaction pool include consensus node-a, consensus node-b, consensus node-c and other consensus nodes ( Figure 5Only consensus node-a, consensus node-c and consensus node-c are provided in it. For the transaction data a3 sent by the object, it is received by consensus node-a, then the consensus node-a can be used as the master node, and other consensus nodes in the transaction pool can be used as slave nodes. After the master node-a receives the transaction data a3 and successfully caches it in the corresponding node partition in the corresponding shard, the consensus node-a can use the consensus node-b and the consensus node-c in the transaction pool as the copy nodes of the transaction data a3 (that is, the consensus nodes for caching the transaction copy data). Further, the consensus node-a can send the copy of the transaction data a3 to the consensus node-b and the consensus node-c, so that the consensus node-b and the consensus node-c cache the copy of the transaction data a3 in the corresponding node partition in the corresponding shard. After the consensus node-b and the consensus node-c successfully cache the copy of the transaction data a3, the consensus node-a will return the transaction write completion notification (that is, the confirmation notification) for the transaction data a3 to the object (the object that sends the transaction data a3, that is, the transaction sending object of the transaction data a3).

[0127] In the embodiment of the present application, by creating different subchains in the blockchain, sharing the same transaction pool for each subchain, and sharding and partitioning the blockchain transaction pool, the transaction data belonging to the same business type can be cached in different partitions in the same shard, and the transaction data can be cached regularly according to the business type and the received consensus node. One transaction data only needs to be cached in one partition of a shard, without repeated caching, which can well reduce the cache redundancy of the transaction data; in addition, this scheme can make the transaction data belonging to the same transaction type be cached in different partitions of the same shard, and when reading the transaction data from the transaction pool, it can be read according to the different transaction types and the different consensus nodes received, which can greatly improve the reading efficiency and reading performance of the transaction data. In summary, the present application can reduce the cache redundancy of transaction data in the transaction pool caching business, and optimize the reading performance of transaction data. The method provided in the embodiment of the present application can also be applied to a multi-chain scenario, where each blockchain in the multi-chain scenario can share the same transaction pool, so the present application can create a shard for each blockchain in the transaction pool, and then divide and set different node partitions for the consensus nodes in each blockchain in each shard.

[0128] Furthermore, it should be understood that in order to improve the security of transaction data, the present application can also store transaction data persistently (such as storing it in a local disk), thereby reducing the loss of transaction data due to node restart (due to persistent storage, transaction data can be obtained from the local disk, thereby improving the reliability of transaction data). For ease of understanding, please refer to Figure 6 , Figure 6 This is a schematic diagram of a process for persistently storing transaction data provided by an embodiment of the present application. This process takes the first consensus node persistently storing the first transaction data as an example. This process can correspond to the above Figure 3 In the corresponding embodiment, the process after caching the first transaction data to the node partition corresponding to the first consensus node. Figure 6 As shown, the process may at least include the following steps S501 to S505:

[0129] Step S501: determine the transaction data stored in the persistent storage component of the first consensus node as the second transaction data.

[0130] Specifically, the persistent storage component of the first consensus node may refer to the local disk of the first consensus node (that is, the disk used to persistently store the data of the first consensus node). The first consensus node may persistently store all received transaction data in the local disk. Before receiving the first transaction data, the first consensus node may have received and stored other transaction data in the local disk. Therefore, before persistently storing the first transaction data in the persistent storage component, the first consensus node may first obtain other transaction data stored in the persistent storage component. These transaction data may all be determined as second transaction data (that is, the second transaction data contained in the persistent storage component may not be one, but may be multiple).

[0131] Step S502: Acquire a first data file for representing first transaction data and a second data file for representing second transaction data.

[0132] Specifically, the data file of the present application may refer to a file used to characterize the transaction content of transaction data, and the transaction content may include the serial number of the transaction data, the contract name for executing the transaction data, the name of the execution method in the contract, the transaction input parameters, the transaction initiator, the transaction signature, etc. These contents of the transaction data may be saved in the data file. Then the first data file may refer to a file used to characterize the transaction content of the first transaction data, which records the serial number, contract name, method name, initiator, transaction signature and other information of the first transaction data, and the data file may be in code form (such as binary code form). The second data file may refer to the sum of the files characterizing the transaction content of each second transaction data (it may refer to a file that splices together the files of the transaction content of each second transaction data).

[0133] Step S503: concatenate the first data file and the second data file to obtain a concatenated file.

[0134] Specifically, the present application may concatenate the first data file and the second data file to obtain a concatenated file.

[0135] Step S504: determining a storage strategy for the first transaction data based on the file length of the concatenated file.

[0136] Specifically, based on the file length of the spliced ​​file, the storage strategy of the first transaction data can be determined. Based on the above, it can be known that the data file can be in code form, so the file length here can refer to the character length (such as the length of the characters contained in the code). Based on the file length, the storage strategy of the first transaction data can be determined. The specific method can be as follows: the file length of the spliced ​​file can be compared with a length threshold, thereby obtaining a first comparison result; if the first comparison result is that the file length of the spliced ​​file is greater than the length threshold, the segmented storage strategy can be determined as the storage strategy for the first transaction data; and if the first comparison result is that the file length of the spliced ​​file is less than the length threshold, the entire segment storage strategy can be determined as the storage strategy for the first transaction data.

[0137] Among them, the segmented storage strategy in this application may refer to splitting the spliced ​​file containing the first transaction data to obtain different segmented sub-files, and then storing each segmented sub-file separately; and the whole segment storage strategy may refer to directly storing the spliced ​​file. It can be understood that when the length of the spliced ​​file is too long (such as greater than the length threshold, the length threshold can be set manually), it is not conducive to locating and querying a certain transaction data (querying the transaction content of the transaction data) in the persistent storage component. Then, this application can facilitate the query (such as binary query) and positioning of transaction data by splitting and then storing it in segments.

[0138] Step S505: store the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data.

[0139] Specifically, after determining the storage strategy of the first transaction data, the first transaction data can be stored in the persistent storage component. Taking the storage strategy of the first transaction data as the whole segment storage strategy as an example, the specific method of storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data can be: the first data file can be directly written to the persistent storage component according to the whole segment storage strategy (for example, the first character of the first data file is stored after the last character of the second data file).

[0140] Taking the storage strategy of the first transaction data as a segmented storage strategy as an example, the specific method of storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data may be: according to the segmented storage strategy, the spliced ​​file may be segmented, thereby obtaining Q segmented sub-files; wherein, one of the Q segmented sub-files contains one or more transaction data; Q is a positive integer; further, the segmented sub-file containing the target transaction data among the Q segmented sub-files may be determined as the target segmented sub-file; and then the target segmented sub-file may be written to the persistent storage file.

[0141] Among them, taking the target slice sub-file containing R (R is a positive integer) transaction data as an example, the specific method of writing the target slice sub-file to the persistent storage file includes: the file position of the first transaction data in the target slice sub-file and the file position of the target slice sub-file in the spliced ​​file can be obtained; further, the file position of the first transaction data in the target slice sub-file can be combined with the first data file, thereby obtaining the transaction write data of the first transaction data; when the transaction write data of each transaction data in the R transaction data is determined, the transaction write data of each transaction data and the file position of the target slice sub-file in the spliced ​​file can be associated and written to the persistent storage file.

[0142] To facilitate understanding of the specific method of splitting and splicing files and writing split sub-files, the following example will be used for explanation. Assume that the data file shown in Table 1 is a spliced ​​file, and the transaction content of transaction data 1 to transaction data 20 is recorded in the spliced ​​file. As shown in Table 1:

[0143] Table 1

[0144] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

[0145] As shown in Table 1, transaction data 20 is the first transaction data. Assuming that the file length of the concatenated file is greater than the length threshold, the concatenated file can be segmented, wherein the segmentation method can be segmented according to a uniform transaction number (such as the number of transaction data contained in each segmented sub-file is 3), or segmented according to multiple transaction numbers (such as the number of transaction data contained in some segmented sub-files is 3, some is 5, some is 7, etc.), but no matter how the segmentation method is, the file length of each segmented sub-file finally obtained will not be greater than the length threshold. For example, here, taking the segmentation file shown in Table 1 as being segmented into 4 segments (i.e., segmented into 4 segmented sub-files) as an example, after the concatenated file is segmented, segmented sub-file 1, segmented sub-file 2, segmented sub-file 3, and segmented sub-file 4 can be obtained, and the transaction data contained in segmented sub-file 1 is transaction data 1-5; the transaction data contained in segmented sub-file 2 is transaction data 6-9, the transaction data contained in segmented sub-file 3 is transaction data 10-14, and the transaction data contained in segmented sub-file 4 is transaction data 15-20. The slice sub-file containing the first transaction data (transaction data 20) is slice sub-file 4, so the slice sub-file 4 can be used as the target slice sub-file and written into the persistent storage component. The target slice sub-file also contains the written transaction data 15-19, so before writing the target slice sub-file into the persistent storage component, the transaction data 15-19 stored in the persistent storage component can be cleared first, and then the target slice sub-file can be written into it, thereby avoiding the situation where the transaction data is written repeatedly.

[0146] It should be noted that when storing and writing a slice sub-file (such as a target slice sub-file), the present application needs to write the file position of the slice sub-file in the concatenated file and the file position of each transaction data in the slice sub-file (that is, the offset index file of the transaction data). In this way, the slice sub-file (found by the file position of the slice sub-file in the concatenated file) and the transaction data in the slice sub-file (found by the file position of the transaction data in the slice sub-file) can be quickly located through the file position, thereby improving the efficiency of transaction data search. For ease of understanding, please refer to Figure 7 , Figure 7 This is a schematic diagram of a data structure for storing transaction data in segments provided by an embodiment of the present application. The data file shown in the figure may refer to an integral file (i.e., a concatenated file) containing the first transaction data. The concatenated file may be divided into N data segments (including data segment 1, data segment 2, ..., data segment N). Each data segment may be understood as a segmentation sub-file of the present application. For each segmentation sub-file, the data file of each transaction data and the offset index file may be written into the persistent storage component. For example, Figure 7 Taking the data segment 4 shown as an example, the data file and offset index file of each transaction data can be obtained, and then the data file and offset index file of each transaction data can be written into the persistent storage component.

[0147] In the embodiment of the present application, by sharding, partitioning and segmented persistent storage of the blockchain transaction pool, the repeated caching of transaction data can be reduced, the cache redundancy of transaction data can be greatly reduced, and the reading performance of transaction data in the transaction pool can be improved; in addition, through segmented persistent storage, data loss caused by node abnormalities can be reduced, and the search efficiency of transaction data in the local disk can be improved.

[0148] For further information, see Figure 8 , Figure 8 This is a schematic diagram of a process for packaging transaction data on a chain provided by an embodiment of the present application. This process may correspond to the above Figure 3 In the corresponding embodiment, the process after the first consensus node caches the first transaction data to the node partition corresponding to the first consensus node. Figure 8 As shown, the process may include at least the following steps S701 to S703:

[0149] Step S701, when a transaction packaging signal is received, the total number of transactions contained in the transaction data in the node partition corresponding to the first consensus node is counted.

[0150] Specifically, the first consensus node may include a core engine component, which may receive a block signal (i.e., a block generation signal, which is used to instruct the first consensus node to package the transaction data into blocks, so the block generation signal is also a transaction packaging signal) from a timer or a transaction pool component. Once the core engine component receives the transaction packaging signal, it may set its own block generation state to a block generation state (the block generation state may indicate that no new "block generation signals" will be processed at present). Subsequently, the first consensus node may call the transaction pool component to obtain a transaction function, through which the transaction data may be obtained. Specifically, the present application may first obtain transaction data from the primary partition (i.e., the node partition of the first consensus node itself, i.e., the node partition corresponding to the first consensus node), and when the transaction data of the primary partition is not enough for the maximum transaction capacity of the block, the transaction data may be obtained from the secondary partition (i.e., the node partition of other consensus nodes). Then, the first consensus node may use the transaction function to count the total number of transactions of the transaction data contained in the node partition corresponding to the first consensus node (the node partition corresponding to the first consensus node in a certain shard).

[0151] It should be noted that the transaction packaging signal here can specifically refer to the transaction packaging signal for a certain subchain, so the node partition corresponding to the first consensus node here can refer to the node partition in a certain shard. Here, the target shard is used as an example for explanation (that is, the received transaction packaging signal is a signal for the subchain corresponding to the target shard), that is, the first consensus node can count the total number of transactions contained in the transaction data from the node partition corresponding to the first consensus node in the target shard.

[0152] Step S702, obtaining the block capacity, comparing the total number of transactions with the block capacity, and obtaining a second comparison result.

[0153] Specifically, for each block on the sub-chain, a different amount of transaction data that can be accommodated can be configured. This amount can be called the block capacity. Here, the total number of transactions in the main partition (i.e., the node partition corresponding to the first consensus node) can be compared with the block capacity, thereby obtaining a second comparison result.

[0154] Step S703, determining the packaged transaction data according to the second comparison result, and performing package processing on the packaged transaction data.

[0155] Specifically, the packaged transaction data can be determined based on the second comparison result, and the specific method is as follows: the second comparison result can be analyzed. If the second comparison result is a comparison result that the total number of transactions is greater than the block capacity, the first transaction data set can be obtained in the node partition corresponding to the first consensus node according to the block capacity, and the first transaction data set is taken as the packaged transaction data; wherein the number of transaction data included in the first transaction data set is the block capacity; and if the second comparison result is a comparison result that the total number of transactions is less than the block capacity, the quantity difference between the block capacity and the total number of transactions can be determined, and the packaged transaction data can be determined based on the quantity difference and the transaction data included in the node partition corresponding to the first consensus node.

[0156] Among them, the specific method for determining packaged transaction data based on the quantity difference and the transaction data contained in the node partition corresponding to the first consensus node can be: the consensus nodes other than the first consensus node in the consensus nodes included in the blockchain can be determined as slave nodes; further, the node partition corresponding to the slave node can be determined as the slave partition; according to the quantity difference, the second transaction data set can be obtained from the slave partition; wherein the number of transaction data contained in the second transaction data set is the quantity difference; further, the transaction data contained in the node partition corresponding to the first consensus node can be jointly determined as packaged transaction data together with the second transaction data set.

[0157] It can be understood that if the total number of transactions of the transaction data contained in the node partition of the first consensus node is greater than or equal to the block capacity, then a batch of transaction data (i.e., the first transaction data set) of the corresponding number (i.e., the block capacity) can be obtained from the node partition of the first consensus node as packaged transaction data; and if the total number of transactions of the transaction data contained in the node partition of the first consensus node is less than the block capacity, then the difference in quantity between the block capacity and the total number of transactions can be determined, and a batch of transaction data (i.e., the second transaction data set) of a certain number (i.e., the difference in quantity) in the slave partition (i.e., the node partition corresponding to other consensus nodes in the target shard) can be used to determine all the transaction data in the node partition of the first consensus node and the first transaction data set as packaged transaction data.

[0158] After determining the packaged transaction data, the packaged transaction data can be packaged to generate a block, and then the block can be added to the subchain corresponding to the target shard. Then for each subchain, the transaction data stored is of the same business type, and the transaction data contained in each block of the subchain is likely to be received by the same consensus node. Based on this, in the business of transaction data query, the corresponding subchain can be located by the business type of transaction data, and then a batch of blocks can be located in the subchain based on the difference in consensus nodes, so that the specified transaction data can be quickly found in these blocks, which can greatly improve the efficiency of transaction data query.

[0159] For easier understanding, please also refer to Fig. 9 , Fig. 9 This is a schematic diagram of a node packaging transaction data architecture provided by an embodiment of the present application. Fig. 9 As shown, the architecture can at least include a core engine component, a transaction pool component, and a consensus component. For ease of understanding, the functions implemented by each component will be specifically described below:

[0160] Core engine component: The core engine component can be used to receive block signals (sent by the timer or transaction pool component). After receiving the block signal, the main partition transaction number (that is, the transaction number of the transaction data contained in the main partition, which is the node partition corresponding to the consensus node to which the core engine component belongs in the shard) can be read from a shard in the transaction pool component. The core engine component can determine whether the main partition transaction number is greater than the maximum number of block transactions (that is, whether it is greater than the block capacity); if the core engine component determines that it is greater than the maximum number of block transactions, it can read the transaction number from the main partition (such as Fig. 90) (i.e., reading the main partition transaction), and determining whether the acquired transaction data is an empty transaction. If the transaction data is not an empty transaction, the transaction can be executed and a block can be generated (i.e., it is used as packaged transaction data and a block is generated and added to the corresponding sub-chain). If the transaction data is an empty transaction, a new block signal can be waited for; and if the core engine component determines that it is less than the maximum number of block transactions, the main partition transaction can be read and the difference can be calculated (the difference is the difference between the block capacity and the total number of transactions in the main partition). Based on the difference, the slave partition (such as Fig. 9 Partition 1 and partition 2) transactions shown (that is, obtaining transaction data from partitions in the shard).

[0161] Consensus component: The blocks generated by the core engine component can be passed to the consensus component, where consensus can be reached on the block. After the block passes the consensus, it can be added to the corresponding sub-face.

[0162] Transaction pool component: It can be used to divide and set different shards and partitions to cache transaction data received by different business types and different consensus nodes, that is, the transaction data can be cached in a standardized manner.

[0163] For the specific description of the functions implemented by each component, please refer to the description in the previous embodiment, which will not be repeated here, and the beneficial effects brought about by it will not be described in detail here either.

[0164] For further information, see Fig.10 , Fig.10 : is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application. The blockchain-based data processing device can be a computer program (including program code) running in a computer device, for example, the blockchain-based data processing device is an application software; the blockchain-based data processing device can be used to execute Figure 3 As shown in the method. Fig.10 As shown, the blockchain-based data processing device 1 may include: an acquisition module 11, a shard determination module 12, a partition acquisition module 13 and a cache module 14.

[0165] An acquisition module 11 is used to acquire first transaction data and a transaction type to which the first transaction data belongs;

[0166] The shard determination module 12 is used to determine, according to the transaction type, a target shard for caching the first transaction data from among the N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer

[0167] The partition acquisition module 13 is used to acquire the node partition corresponding to the first consensus node from the M node partitions provided in the target shard; M is a positive integer;

[0168] The cache module 14 is used to cache the first transaction data in the node partition corresponding to the first consensus node.

[0169] The specific implementation of the acquisition module 11, the shard determination module 12, the partition acquisition module 13 and the cache module 14 can be found in the above Figure 3 The description of step S101 to step S103 in the corresponding embodiment will not be repeated here.

[0170] In one embodiment, after the cache module 14 caches the first transaction data into the node partition corresponding to the first consensus node, the blockchain-based data processing device 1 further includes: a node determination module 15 and a copy sending module 16.

[0171] A node determination module 15, configured to determine, among the consensus nodes included in the blockchain, a second consensus node for caching the first transaction data;

[0172] The copy sending module 16 is used to send the transaction copy data of the first transaction data to the second consensus node, so that the second consensus node obtains the node partition corresponding to the second consensus node in the M node partitions set in the target shard, and caches the transaction copy data in the node partition corresponding to the second consensus node.

[0173] The specific implementation of the node determination module 15 and the replica sending module 16 can be found in the above Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0174] In one embodiment, the node determination module 15 determines a specific implementation method of a second consensus node for caching the first transaction data among the consensus nodes included in the blockchain, including:

[0175] Get the consensus node cluster contained in the blockchain;

[0176] Count the total number of consensus nodes contained in the consensus node cluster, and perform calculations on the total number of nodes and the specified ratio to obtain the calculation quantity;

[0177] Obtain W consensus nodes in the consensus node cluster according to the number of operations; W is the number of operations;

[0178] W consensus nodes are determined as second consensus nodes for caching the first transaction data.

[0179] In one embodiment, after the cache module 14 caches the first transaction data in the node partition corresponding to the first consensus node, the blockchain-based data processing device 1 also includes: a transaction determination module 17, a file acquisition module 18, a splicing module 19, a policy determination module 20 and a persistent storage module 21.

[0180] The transaction determination module 17 is used to determine the transaction data stored in the persistent storage component of the first consensus node as the second transaction data;

[0181] A file acquisition module 18, used to acquire a first data file for representing the first transaction data, and a second data file for representing the second transaction data;

[0182] A splicing module 19, used for splicing the first data file with the second data file to obtain a spliced ​​file;

[0183] A strategy determination module 20, configured to determine a storage strategy for the first transaction data based on a file length of the concatenated file;

[0184] The persistent storage module 21 is used to store the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data.

[0185] The specific implementation of the transaction determination module 17, the file acquisition module 18, the splicing module 19, the strategy determination module 20 and the persistent storage module 21 can be found in the above Figure 6 The description of steps S501 to S505 in the corresponding embodiment will not be repeated here.

[0186] In one embodiment, the strategy determination module 20 determines a specific implementation of the storage strategy for the first transaction data based on the file length of the concatenated file, including:

[0187] Compare the file length of the concatenated file with the length threshold to obtain a first comparison result;

[0188] If the first comparison result is that the file length of the spliced ​​file is greater than the length threshold, the segment storage strategy is determined as the storage strategy for the first transaction data;

[0189] If the first comparison result is that the file length of the spliced ​​file is less than the length threshold, the entire storage strategy is determined as the storage strategy for the first transaction data.

[0190] In one embodiment, the storage strategy of the target transaction data is a segmented storage strategy;

[0191] The specific implementation method of the persistent storage module 21 storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data includes:

[0192] According to the segment storage strategy, the spliced ​​file is segmented to obtain Q segmented sub-files; one of the Q segmented sub-files contains one or more transaction data; Q is a positive integer;

[0193] Determine a slice sub-file containing target transaction data among the Q slice sub-files as a target slice sub-file;

[0194] Write the target segmentation sub-file to the persistent storage file.

[0195] In one embodiment, the target segmentation subfile contains R transaction data; R is a positive integer;

[0196] The specific implementation method of the persistent storage module 21 writing the target segmentation sub-file into the persistent storage file includes:

[0197] Obtaining a file position of the first transaction data in the target slice sub-file and a file position of the target slice sub-file in the spliced ​​file;

[0198] Combining the file position of the first transaction data in the target slice subfile with the first data file to obtain transaction write data of the first transaction data;

[0199] When the transaction write data of each transaction data in the R transaction data is determined, the transaction write data of each transaction data and the file position of the target slice sub-file in the spliced ​​file are associated and written into the persistent storage file.

[0200] In one embodiment, the storage strategy for the first transaction data is a whole-segment storage strategy;

[0201] The specific implementation method of the persistent storage module 21 storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data includes:

[0202] According to the whole-segment storage strategy, the first data file is written to the persistent storage component.

[0203] In one embodiment, the number of second consensus nodes is at least two;

[0204] After the copy sending module 16 sends the transaction copy data of the first transaction data to the second consensus node, the blockchain-based data processing device 1 also includes: a response node acquisition module 22, a node quantity statistics module 23, a ratio determination module 24 and a notification push module 25.

[0205] The response node acquisition module 22 is used to acquire a response node from at least two second consensus nodes when the message statistics time is reached; the response node refers to the second consensus node that sends a copy storage completion notification to the first consensus node before the message statistics time is reached;

[0206] A node quantity counting module 23, used to count a first quantity of response nodes and a second quantity of at least two second consensus nodes;

[0207] a ratio determination module 24, configured to determine a quantity ratio between the first quantity and the second quantity;

[0208] The notification push module 25 is used to push a write completion notification to a transaction sending object if the quantity ratio is greater than a ratio threshold; the transaction sending object refers to an object that sends the first transaction data;

[0209] The notification push module 25 is further used to push a write failure notification to the transaction sending object if the quantity ratio is less than the ratio threshold.

[0210] The specific implementation methods of the response node acquisition module 22, the node quantity counting module 23, the ratio determination module 24 and the notification push module 25 can be referred to in the above Figure 3 The relevant description in step S103 in the corresponding embodiment will not be repeated here.

[0211] In one embodiment, after the cache module 14 caches the first transaction data into the node partition corresponding to the first consensus node, the blockchain-based data processing device 1 further includes: a quantity statistics module 26, a comparison module 27 and a transaction packaging module 28.

[0212] The quantity statistics module 26 is used to count the total number of transactions contained in the node partition corresponding to the first consensus node when receiving the transaction packaging signal;

[0213] A comparison module 27, used to obtain the block capacity, compare the total number of transactions with the block capacity, and obtain a second comparison result;

[0214] A transaction packaging module 28, configured to determine the packaged transaction data according to the second comparison result;

[0215] The transaction packaging module 28 is also used to package the packaged transaction data.

[0216] The specific implementation of the quantity statistics module 26, the comparison module 27 and the transaction packaging module 28 can be found in the above Figure 8 The description of steps S701 to S703 in the corresponding embodiment will not be repeated here.

[0217] In one embodiment, the transaction packaging module 28 determines a specific implementation method of packaging the transaction data according to the second comparison result, including:

[0218] If the second comparison result is that the total number of transactions is greater than the block capacity, the first transaction data set is obtained in the node partition corresponding to the first consensus node according to the block capacity, and the first transaction data set is taken as packaged transaction data; the number of transaction data included in the first transaction data set is the block capacity;

[0219] If the second comparison result is that the total number of transactions is less than the block capacity, the quantity difference between the block capacity and the total number of transactions is determined, and the packaged transaction data is determined based on the quantity difference and the transaction data contained in the node partition corresponding to the first consensus node.

[0220] In one embodiment, the transaction packaging module 28 determines a specific implementation method for packaging transaction data based on the quantity difference and the transaction data contained in the node partition corresponding to the first consensus node, including:

[0221] Determine the consensus nodes other than the first consensus node among the consensus nodes included in the blockchain as slave nodes;

[0222] Determine the node partition corresponding to the slave node as the slave partition;

[0223] Obtaining a second transaction data set from the partition according to the quantity difference; the quantity of transaction data included in the second transaction data set is the quantity difference;

[0224] The transaction data contained in the node partition corresponding to the first consensus node and the second transaction data set are jointly determined as packaged transaction data.

[0225] In the embodiment of the present application, by creating different sub-chains in the blockchain, sharing the same transaction pool for each sub-chain, and sharding and partitioning the blockchain transaction pool, the transaction data belonging to the same business type can be cached in different partitions in the same shard, and the transaction data can be cached regularly according to the business type and the received consensus node. One transaction data only needs to be cached in one partition of a shard, and there is no need for repeated caching, which can well reduce the cache redundancy of the transaction data; in addition, this scheme can make the transaction data belonging to the same transaction type be cached in different partitions of the same shard. When reading the transaction data from the transaction pool, it can be read according to the different transaction types and the different received consensus nodes, which can greatly improve the reading efficiency and reading performance of the transaction data. In summary, the present application can reduce the cache redundancy of transaction data in the transaction pool cache business, and at the same time optimize the reading performance of transaction data.

[0226] For further information, see Fig.11 , Fig.11 Schematic diagram of the structure of a computer device provided in an embodiment of the present application. Fig.11 As shown, the above-mentioned computer device 8000 may include: a processor 8001, a network interface 8004 and a memory 8005. In addition, the above-mentioned computer device 8000 also includes: a user interface 8003, and at least one communication bus 8002. Among them, the communication bus 8002 is used to realize the connection and communication between these components. Among them, the user interface 8003 may include a display screen (Display), a keyboard (Keyboard), and the optional user interface 8003 may also include a standard wired interface and a wireless interface. The network interface 8004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 8005 may be a high-speed RAM memory, or it may be a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 8005 may optionally also be at least one storage device located away from the aforementioned processor 8001. As Fig.11 As shown, the memory 8005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application.

[0227] exist Fig.11 In the computer device 8000 shown, the network interface 8004 can provide a network communication function; the user interface 8003 is mainly used to provide an input interface for the user; and the processor 8001 can be used to call the device control application stored in the memory 8005 to achieve:

[0228] Acquire first transaction data and a transaction type to which the first transaction data belongs;

[0229] According to the transaction type, a target shard for caching the first transaction data is determined from N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer;

[0230] Among the M node partitions provided in the target shard, the node partition corresponding to the first consensus node is obtained, and the first transaction data is cached in the node partition corresponding to the first consensus node; M is a positive integer.

[0231] It should be understood that the computer device 8000 described in the embodiment of the present application can execute the above Figures 3 to 8 The description of the data processing method based on blockchain in the corresponding embodiment can also be performed as described above. Fig.10The description of the blockchain-based data processing device 1 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0232] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the data processing computer device 8000 mentioned above, and the computer program includes program instructions. When the processor executes the program instructions, the computer program can execute the above-mentioned data processing computer device 8000. Figures 3 to 8 The description of the above-mentioned blockchain-based data processing method in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0233] The computer-readable storage medium may be a data processing device based on blockchain provided in any of the aforementioned embodiments or an internal storage unit of the computer device, such as a hard disk or memory of a computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flash card), etc. equipped on the computer device. Furthermore, the computer-readable storage medium may also include both an internal storage unit of the computer device and an external storage 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 may also be used to temporarily store data that has been output or is to be output.

[0234] In one aspect of the present application, a computer program product is provided, the computer program product comprising a computer program, the computer program being stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device executes the method provided in one aspect of the embodiments of the present application.

[0235] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the term "comprising" and any of their variations are intended to cover non-exclusive inclusions. 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 optionally includes steps or modules that are not listed, or optionally includes other step units inherent to these processes, methods, devices, products, or equipment.

[0236] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0237] The method and related apparatus provided by the embodiment of the present application are described with reference to the method flow chart and / or structural diagram provided by the embodiment of the present application. Specifically, each process and / or box in the method flow chart and / or structural diagram, as well as the combination of the processes and / or boxes in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the process in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 Schematic diagram of one or more processes and / or structures Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A flow or multiple flows and / or structures illustrate the steps of the functions specified in one block or multiple blocks.

[0238] The above disclosure is only the preferred embodiment of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A data processing method based on blockchain, characterized in that: The method is performed by a first consensus node in the blockchain, and the method includes: Acquire first transaction data and a transaction type to which the first transaction data belongs; According to the transaction type, a target shard for caching the first transaction data is determined from the N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer; Among the M node partitions provided in the target shard, obtain the node partition corresponding to the first consensus node, and cache the first transaction data into the node partition corresponding to the first consensus node; M is a positive integer.

2. The method according to claim 1, characterized in that After caching the first transaction data in the node partition corresponding to the first consensus node, the method further includes: Determining, among the consensus nodes included in the blockchain, a second consensus node for caching the first transaction data; The transaction copy data of the first transaction data is sent to the second consensus node, so that the second consensus node obtains the node partition corresponding to the second consensus node in the M node partitions set in the target shard, and caches the transaction copy data in the node partition corresponding to the second consensus node.

3. The method according to claim 2, characterized in that The step of determining, among the consensus nodes included in the blockchain, a second consensus node for caching the first transaction data comprises: Obtaining the consensus node cluster contained in the blockchain; Counting the total number of consensus nodes included in the consensus node cluster, and performing calculation processing on the total number of nodes and a specified ratio to obtain a calculation number; Obtain W consensus nodes in the consensus node cluster according to the number of operations; W is the number of operations; The W consensus nodes are determined as second consensus nodes for caching the first transaction data.

4. The method according to claim 1, characterized in that: After caching the first transaction data in the node partition corresponding to the first consensus node, the method further includes: Determining the transaction data stored in the persistent storage component of the first consensus node as second transaction data; Acquire a first data file for representing the first transaction data, and a second data file for representing the second transaction data; Splicing the first data file with the second data file to obtain a spliced ​​file; Determining a storage strategy for the first transaction data based on a file length of the concatenated file; According to the storage strategy of the first transaction data, the first transaction data is stored in the persistent storage component of the first consensus node.

5. The method according to claim 4, characterized in that The determining the storage strategy of the first transaction data based on the file length of the concatenated file includes: Compare the file length of the spliced ​​file with a length threshold to obtain a first comparison result; If the first comparison result is that the file length of the spliced ​​file is greater than the length threshold, determining the segmented storage strategy as the storage strategy for the first transaction data; If the first comparison result is that the file length of the spliced ​​file is less than the length threshold, the entire segment storage strategy is determined as the storage strategy for the first transaction data.

6. The method according to claim 4, characterized in that The storage strategy of the target transaction data is a segmented storage strategy; The storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data includes: According to the segmented storage strategy, the spliced ​​file is segmented to obtain Q segmented sub-files; one of the Q segmented sub-files contains one or more transaction data; Q is a positive integer; Determine a slice sub-file containing the target transaction data among the Q slice sub-files as a target slice sub-file; Write the target segmentation subfile to the persistent storage file.

7. The method according to claim 5, characterized in that The target segmentation subfile contains R transaction data; R is a positive integer; The step of writing the target segmentation sub-file into the persistent storage file comprises: Acquire the file position of the first transaction data in the target slice sub-file and the file position of the target slice sub-file in the spliced ​​file; Combining the file position of the first transaction data in the target slice subfile with the first data file to obtain transaction write data of the first transaction data; When the transaction write data of each transaction data in the R transaction data is determined, the transaction write data of each transaction data and the file position of the target slice sub-file in the spliced ​​file are associated and written into the persistent storage file.

8. The method according to claim 4, characterized in that The storage strategy of the first transaction data is a whole-segment storage strategy; The storing the first transaction data in the persistent storage component of the first consensus node according to the storage strategy of the first transaction data includes: According to the entire segment storage strategy, the first data file is written to the persistent storage component.

9. The method according to claim 2, characterized in that: The number of the second consensus nodes is at least two; After sending the transaction copy data of the first transaction data to the second consensus node, the method further includes: When the message statistics time is reached, a response node is obtained from at least two second consensus nodes; the response node refers to the second consensus node that sends a copy storage completion notification to the first consensus node before the message statistics time is reached; Counting a first number of the response nodes and a second number of the at least two second consensus nodes; determining a quantity ratio between the first quantity and the second quantity; If the quantity ratio is greater than the ratio threshold, a write completion notification is pushed to the transaction sending object; the transaction sending object refers to the object that sent the first transaction data; If the quantity ratio is less than the ratio threshold, a write failure notification is pushed to the transaction sending object.

10. The method according to claim 1, characterized in that After caching the first transaction data in the node partition corresponding to the first consensus node, the method further includes: When receiving the transaction packaging signal, counting the total number of transactions contained in the transaction data in the node partition corresponding to the first consensus node; Obtaining a block capacity, and comparing the total number of transactions with the block capacity to obtain a second comparison result; The packaged transaction data is determined according to the second comparison result, and the packaged transaction data is packaged and processed.

11. The method according to claim 10, characterized in that The step of determining the packaged transaction data according to the second comparison result includes: If the second comparison result is that the total number of transactions is greater than the block capacity, then obtaining a first transaction data set in the node partition corresponding to the first consensus node according to the block capacity, and combining the first transaction data set as packaged transaction data; the number of transaction data included in the first transaction data set is the block capacity; If the second comparison result is that the total number of transactions is less than the block capacity, the quantity difference between the block capacity and the total number of transactions is determined, and the packaged transaction data is determined based on the quantity difference and the transaction data contained in the node partition corresponding to the first consensus node.

12. The method according to claim 10, characterized in that The step of determining the packaged transaction data based on the quantity difference and the transaction data contained in the node partition corresponding to the first consensus node includes: Determine consensus nodes other than the first consensus node among the consensus nodes included in the blockchain as slave nodes; Determine the node partition corresponding to the slave node as a slave partition; Acquire a second transaction data set from the slave partition according to the quantity difference; the quantity of transaction data included in the second transaction data set is the quantity difference; The transaction data contained in the node partition corresponding to the first consensus node and the second transaction data set are jointly determined as packaged transaction data.

13. A data processing device based on blockchain, characterized in that: include: An acquisition module, used to acquire first transaction data and a transaction type to which the first transaction data belongs; A shard determination module is used to determine, according to the transaction type, a target shard for caching the first transaction data from among N shards provided in the transaction pool of the blockchain; the blockchain includes N subchains, and the N subchains share the transaction pool of the blockchain; the N shards are divided and set based on the N subchains in the transaction pool of the blockchain, and one shard corresponds to one subchain; N is a positive integer A partition acquisition module, used to acquire the node partition corresponding to the first consensus node from the M node partitions provided in the target shard; M is a positive integer; A cache module is used to cache the first transaction data in a node partition corresponding to the first consensus node.

14. A computer device, characterized in that: include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide a network communication function, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method described in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the method according to any one of claims 1 to 12.

16. A computer program product, characterized in that The computer program product comprises a computer program, which is stored in a computer-readable storage medium. The computer program is suitable for being read and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 12.

Images