Data processing method and device applied to block chain and storage medium

Abstract

The invention discloses a data processing method and device applied to a block chain and a storage medium, and belongs to the technical field of block chains. The method is applied to any node in a block chain, and comprises the following steps: in response to a transaction request, calculating a read-write set corresponding to a transaction identifier based on transaction data corresponding to the transaction identifier in the transaction request; the read-write set is added into a read-write set table, the read-write set table is used for recording the relationship between a transaction identifier of a first target transaction and a read-write set corresponding to the transaction identifier, and the first target transaction is a transaction which is processed by the node but is not solidified in a block by the node; and generating a block based on the transaction data of the first target transaction and the read-write set table under the condition that the block generation requirement is met. According to the invention, streaming processing of the transaction data and block generation based on the streaming processing result can be realized, the block generation efficiency is improved, the block generation speed of the block chain system is improved, and the stability of the block chain system is also improved.

Description

Technical Field

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

[0002] In traditional blockchain transaction data processing schemes, master and slave nodes often need to wait for each other while processing data. This waiting process incurs time and wastes resources for both the master and slave nodes. Consequently, traditional blockchain transaction data processing schemes fail to fully utilize the CPU (Central Processing Unit) and memory resources of each node, resulting in low verification efficiency and a large amount of computational redundancy, which in turn limits the performance of blockchain systems. Summary of the Invention

[0003] The embodiments of the present application provide a data processing method, device, and storage medium applied to blockchain to solve at least one of the aforementioned technical problems.

[0004] According to one aspect of an embodiment of the present application, a data processing method applied to a blockchain is provided, which is applied to a target node, where the target node is any node in a blockchain system. The method includes:

[0005] In response to a transaction request, calculating a read-write set corresponding to the transaction identifier based on transaction data corresponding to the transaction identifier in the transaction request;

[0006] Adding the read-write set to a read-write set table, where the read-write set table is used to record the association between the transaction identifier of a first target transaction and the read-write set corresponding to the transaction identifier, where the first target transaction is a transaction processed by the target node but not yet solidified in a block by the target node;

[0007] When block generation requirements are met, a block is generated based on the transaction data of the first target transaction and the read-write set table.

[0008] According to one aspect of an embodiment of the present application, a data processing device applied to a blockchain is provided, which is applied to a target node, where the target node is any node in a blockchain system. The device includes:

[0009] a transaction request response module, configured to respond to a transaction request and calculate a read-write set corresponding to the transaction identifier based on transaction data corresponding to the transaction identifier in the transaction request;

[0010] Adding the read-write set to a read-write set table, where the read-write set table is used to record the association between the transaction identifier of a first target transaction and the read-write set corresponding to the transaction identifier, where the first target transaction is a transaction processed by the target node but not yet solidified in a block by the target node;

[0011] The block generation module is configured to generate a block based on the transaction data of the first target transaction and the read-write set table when a block generation requirement is met.

[0012] According to one aspect of an embodiment of the present application, a computer device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the above-mentioned data processing method applied to blockchain.

[0013] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, wherein the storage medium stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the above-mentioned data processing method applied to blockchain.

[0014] According to one aspect of an embodiment of the present application, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to implement the aforementioned data processing method for blockchain.

[0015] The technical solutions provided in the embodiments of the present application can bring the following beneficial effects:

[0016] The embodiment of the present application provides a data processing solution applied to the blockchain. Different from the technical solution in the related art that after the master node completes the data processing, the slave node performs the same data processing, and the master node is idle while the slave node performs the data processing, in the data processing solution provided by the embodiment of the present application, the target node can immediately perform the data processing corresponding to the transaction request upon receiving the transaction request, without the need to wait. The target node is any node in the blockchain system, that is, the target node can serve as a master node or a slave node. Therefore, the master and slave nodes can immediately perform the data processing corresponding to the transaction request upon receiving the transaction request, without the need to wait. Specifically, for the master node, there is no need to wait for the block to be packaged before uniformly performing the data processing of the transaction. For the slave node, there is no need to wait for the block broadcast by the master node before performing data processing on the transaction in the block. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1A This is a schematic diagram of a data sharing system provided by an embodiment of the present application;

[0019] Figure 1B This is a blockchain schematic diagram 1 provided by an embodiment of the present application;

[0020] Figure 1C This is a schematic diagram of a blockchain provided by an embodiment of the present application. Figure 2 ;

[0021] Figure 2 This is a flowchart of a data processing method applied to a blockchain provided by one embodiment of the present application;

[0022] Figure 3 This is a flow chart of a transaction request response method provided by an embodiment of the present application;

[0023] Figure 4 This is a flowchart of a method for verifying a fifth target transaction provided by an embodiment of the present application;

[0024] Figure 5 This is a flowchart of the concurrent conflict resolution logic provided by one embodiment of the present application;

[0025] Figure 6 This is a schematic diagram of the logical structure within a target node provided by an embodiment of the present application;

[0026] Figure 7 This is a flowchart of a method for a target node to perform streaming data processing in a specific implementation manner provided by an embodiment of the present application;

[0027] Figure 8 This is a flowchart of a target node performing block verification in a specific implementation manner provided by an embodiment of the present application;

[0028] Figure 9 This is a schematic diagram of a process for a target node to package blocks in a specific implementation manner provided by an embodiment of the present application;

[0029] Figure 10 This is a schematic diagram of a process for data processing by a target node provided by an embodiment of the present application;

[0030] Figure 11 This is a block diagram of a data processing device applied to blockchain provided by one embodiment of the present application;

[0031] Figure 12 This is a structural block diagram of a computer device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0032] Before introducing the method embodiments provided in the present application, a brief introduction is first given to the relevant terms or nouns that may be involved in the method embodiments of the present application to facilitate understanding by those skilled in the art in the field of the present application.

[0033] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to enable data computing, storage, processing, and sharing. Cloud technology is a general term for network, information technology, integration technology, management platform technology, and application technology, all based on the cloud computing business model. It can form a resource pool that can be used on demand with flexibility and convenience. Cloud computing technology will become a crucial support. Backend services for technical network systems, such as video websites, image websites, and more portals, require extensive computing and storage resources. With the rapid development and application of the internet industry, every item will likely have its own unique identification mark and will need to be transmitted to backend systems for logical processing. Data of varying levels will be processed separately, and data from all industries will require a strong system backend, which can only be achieved through cloud computing.

[0034] A distributed system is a software system built on a network that is highly cohesive and transparent. Compared to traditional centralized systems, distributed systems divide tasks into multiple parts and assign them to different computers for processing, thereby improving the performance and reliability of the system. The characteristics of distributed systems include: High cohesion: The various components in a distributed system are tightly coupled, and task allocation and data exchange are all completed within the system without the need for external intervention. Transparency: Users or applications of a distributed system do not need to care about the internal structure and details of the system; they only need to interact with the system through interfaces. Reliability: Each component in a distributed system can operate independently, and the failure of a component will not paralyze the entire system. Scalability: Distributed systems can easily add or reduce nodes to adapt to changes in business needs. High performance: By assigning tasks to multiple nodes for processing, distributed systems can significantly improve the system's processing power and response speed.

[0035] Blockchain: A distributed ledger technology in the information technology field, generally composed of consensus, transaction blocks, state data storage, and cryptographic identity security. Because the ledger is distributed and blocks are agreed upon, it is tamper-proof, traceable, and jointly maintained. Each node in a blockchain system, or blockchain network, has complete transaction information for the entire blockchain network and maintains its own block ledger. Each node can package and verify blocks, acting as either a master or a slave. Specifically, the node that packages and generates a block is considered a master node, while the node that receives the block is considered a slave node. A node that receives and verifies a block is considered a slave node.

[0036] Smart Contracts: A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts allow for trusted, irreversible transactions without a third party. Nodes generate read-write sets based on smart contracts and transaction data.

[0037] Blockchain ledger: The blockchain is the core data structure in a blockchain system, used to store and manage all confirmed blocks. Organized in a chain-like structure, each block contains a set of transactions, a block header (including the hash value of the previous block, timestamp, and other metadata), and other information. The blockchain provides a public, immutable record of transaction history, ensuring transparency and consistency.

[0038] State data: State data is a data structure used in blockchain systems to represent the current state of the system. State data includes the balances of all accounts, the status of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a certain point in time. In blockchain systems, state data is typically stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security. A Merkle tree, also known as a Merkle tree or hash tree, is a binary tree structure consisting of a root node, several intermediate nodes, and several leaf nodes. Each leaf node in the Merkle tree is used to store data, while non-leaf nodes store the hash value of the contents of their child nodes. In blockchains, Merkle trees are often used to quickly summarize and verify the existence and integrity of block data.

[0039] Transaction Pool: A transaction pool is a data structure in a blockchain system that stores pending transactions that have not yet been included in a block. When a new transaction is submitted to the blockchain system, it first enters the transaction pool. When a blockchain node prepares to generate a new block, it selects a certain number of transactions from the transaction pool for inclusion. The transaction pool helps improve the processing power of the blockchain system and can also serve as a strategy for nodes generating the blockchain to prioritize transactions with higher transaction fees for inclusion, thereby increasing node profits.

[0040] Read-Write Set: A read-write set refers to the set of read and modification operations performed on state data by a blockchain system based on a smart contract during a transaction. It typically consists of two parts: the Read Set and the Write Set. The Read Set records the state data read during a transaction and its corresponding version information; the Write Set records the state data that needs to be modified during a transaction and its updated value. The Read-Write Set is critical information in the blockchain smart contract execution and consensus process, used to verify the correctness and consistency of transactions.

[0041] Read-write set feedback: This system uses read-write sets to determine whether conflicts arise when executing transactions in parallel, and if so, resolves them. This allows for real-time detection and resolution of transaction conflicts, improving blockchain system performance and verification efficiency. Read-write set feedback can also help optimize the order of transaction execution and verification, avoiding unnecessary computational redundancy.

[0042] Before describing the embodiments of the present application in detail, the relevant technical background related to the embodiments of the present application is introduced to facilitate understanding by those skilled in the art in the art of the present application.

[0043] In traditional blockchain transaction data processing schemes, data processing on both master and slave nodes is performed in batches, based on block packaging. Specifically, the master node first packages the block, processes the transactions within it, and places the resulting transaction results into the block. The master node then broadcasts the packaged block to the slave nodes, which then perform a similar process to verify the transactions. If the verification results are identical, consensus succeeds; otherwise, it fails. Therefore, while the master node is processing transactions within the block, the slave nodes are waiting. Similarly, while the slave nodes are performing the same data processing, the master node may also be waiting for the next package. Consequently, both master and slave nodes waste time and resources due to this waiting process.

[0044] Clearly, traditional blockchain transaction data processing solutions fail to fully utilize the CPU (Central Processing Unit) and memory resources of each node, limiting the performance of the blockchain system and resulting in low verification efficiency. When validating blocks, traditional solutions require slave nodes to re-execute transactions to verify the correctness of the results, resulting in a significant amount of computational redundancy. This approach reduces the verification efficiency of the blockchain system and impacts the performance of the entire system.

[0045] In view of this, the embodiment of the present application provides a data processing solution applied to the blockchain, which is different from the technical solution in the related art that the master node performs the same data processing on the slave node after the data processing is completed, and the master node is idle when the slave node performs data processing. The data processing solution provided by the embodiment of the present application can be performed immediately by the master and slave nodes when a transaction request is received, without waiting. For the master node, there is no need to wait for the block to be packaged before uniformly performing data processing on the transaction. For the slave node, there is no need to wait for the block broadcast by the master node before performing data processing. When the master node is packaging the block, it can improve the block packaging speed based on the data processing results obtained when the transaction request is obtained, without batch calculation of all the transactions involved in the block. When the slave node verifies the block, it can also improve the block verification speed based on the data processing results obtained when the transaction request is obtained, without recalculating each transaction in the block.

[0046] Therefore, the data processing scheme provided in the embodiment of the present application can be understood as a pre-execution scheme for data processing. Since the master and slave nodes can directly respond to transaction requests without waiting, the pre-execution scheme for data processing is essentially a streaming data pre-processing scheme. This streaming data pre-processing scheme proposes a strategy for optimizing blockchain transaction processing. The master and slave nodes no longer need to wait for each other, and can make full use of the CPU and memory resources of the master and slave nodes of the blockchain. The total process time of the traditional blockchain data processing scheme includes receiving a number of transactions, performing batch calculations based on the transactions, packaging blocks according to the calculation results, and completing block verification. The total process time includes the time that the master and slave nodes wait for each other. In the data processing scheme applied to the blockchain proposed in the embodiment of the present application, the total process time is greatly shortened, so that the time for data processing related to the transaction is almost equal to the total process time, that is, there is almost no waiting time, and the transaction request can be responded to at any time, which also reduces the time and resource occupation of centralized data processing of multiple transactions, thereby maximizing the performance of the blockchain system. Furthermore, this data processing solution can also improve the verifiability of transaction results, allowing blockchain nodes to directly use the already acquired data processing results for verification when verifying blocks, reducing computational redundancy and improving the performance of the entire blockchain system.

[0047] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0048] See also Figure 1A The data sharing system shown, data sharing system 100, refers to a system for sharing data between nodes. The data sharing system may include multiple nodes 101, which may be clients in the data sharing system. The data sharing system may provide or participate in the blockchain that implements the data processing solution in the embodiments of the present application.

[0049] Each node 101 can receive input information during normal operation and maintain the shared data within the data sharing system based on the received input information. In order to ensure information intercommunication within the data sharing system, an information connection can exist between each node in the data sharing system, and information can be transmitted between nodes through the above information connection. For example, when any node in the data sharing system receives input information, the other nodes in the data sharing system obtain the input information according to the consensus algorithm and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0050] Each node in the data sharing system has a corresponding node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system so that the generated blocks can be broadcast to other nodes in the data sharing system based on the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the table below, and store the node name and node identifier in the node identifier list accordingly. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node. Table 1 only uses the IP address as an example for explanation.

[0051]

[0052]

[0053] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1B The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block uses the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0054] When generating each block in the blockchain, see Figure 1C When the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried. The eigenvalue calculation is performed multiple times so that the calculated eigenvalue can satisfy the following formula:

[0055] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

[0056] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0057] In this way, when a random number that satisfies the above formula is calculated, the information can be stored accordingly, and the block header and block body can be generated to obtain the current block. Subsequently, the blockchain node sends the newly generated block to other nodes in the data sharing system based on the node identifiers of other nodes in the data sharing system. The other nodes verify the newly generated block and, after verification, add the newly generated block to their stored blockchain.

[0058] Please refer to Figure 2 , which shows a flow chart of a data processing method applied to a blockchain, provided by one embodiment of the present application. This method is applied to a target node, which is any node in the blockchain system. During the block packaging phase, the target node can be considered a master node, and during the block verification phase, the target node can be considered a slave node.

[0059] S201. In response to a transaction request, a read-write set corresponding to the transaction identifier is calculated based on transaction data corresponding to the transaction identifier in the transaction request.

[0060] In the embodiment of the present application, security verification can be performed immediately after receiving the transaction request, and if the verification is passed, the transaction data can be calculated immediately to obtain the corresponding read-write set. The embodiment of the present application does not limit the security verification method. For example, the certificate and / or signature related to the transaction request can be verified. In some embodiments, the transaction request can first enter the transaction pool, and after entering the transaction pool, the transaction request can be verified immediately in response to the transaction request. For the transaction request that passes the verification, the transaction data is immediately calculated to obtain the corresponding read-write set. Unlike the related art, the embodiment of the present application does not wait until the block is packaged to calculate the transaction data, but instead calculates the transaction data immediately in response to the transaction request.

[0061] Please refer to Figure 3 , which shows a flow chart of the transaction request response method according to an embodiment of the present application. The flow chart includes the following operations:

[0062] S301. The account issues a transaction request, signs the content of the transaction request, attaches the signature to the transaction request, and sends it to the target node.

[0063] Of course, the embodiment of the present application does not limit the signing method.

[0064] S302. The target node performs certificate verification and signature verification on the transaction request.

[0065] Of course, the embodiment of the present application does not limit the verification methods of certificate verification and signature verification.

[0066] S303. If either the certificate verification or the signature verification fails, the transaction request is rejected.

[0067] S304. When both the certificate verification and the signature verification are passed, the read-write set corresponding to the transaction identifier is calculated based on the transaction data corresponding to the transaction identifier in the transaction request.

[0068] The embodiment of the present application does not elaborate on the details of the process of calculating transaction data and obtaining the read-write set. The execution details are also related to the specific smart contract. Omission of the execution details does not affect the implementation of the embodiment of the present application.

[0069] S202. Add the read-write set to a read-write set table, where the read-write set table is used to record the association between the transaction identifier of the first target transaction and the read-write set corresponding to the transaction identifier. The first target transaction is a transaction that has been processed by the target node but has not yet been solidified in the block by the target node.

[0070] In the embodiment of the present application, each node maintains its own read-write set table, which records the processing results obtained by the node through streaming data processing of the acquired transaction data. The processing results are not yet fixed in the block by the node. Once the node uses the processing results to package the block, the processing results will be deleted from the read-write set table. Moreover, when the node verifies the block, if the node finds that the processing results have been fixed in the block by other nodes, the processing results will still be deleted from the read-write set table.

[0071] S203. When the block generation requirements are met, generate a block based on the transaction data of the first target transaction and the read-write set table.

[0072] This embodiment of the present application does not limit the block generation requirement. A timer can be set that is triggered at regular intervals. When triggered, step S203 is executed, indicating that the block generation requirement has been met. Alternatively, the block generation requirement can be considered met when the number of transactions in the transaction pool meets a preset first quantity requirement, or when the number of transactions in the read / write set table meets a preset second quantity requirement. Of course, this embodiment of the present application does not limit the first and second quantity requirements, and they can be set according to actual circumstances. Both the first and second quantities are greater than 1.

[0073] In one embodiment, when the block generation requirement is met, generating a block based on the transaction data of the first target transaction and the read-write set table includes: when the block generation requirement is met and the number of the first target transactions is greater than or equal to a block transaction number threshold, determining a second target transaction, the second target transaction being the first target transaction that participates in constituting the block; reading a read-write set sub-table corresponding to the second target transaction in the read-write set table, and deleting the read-write set sub-table in the read-write set table; and generating a block based on the reading result and the transaction data corresponding to the second target transaction.

[0074] This application does not limit the threshold value of the number of block transactions, which can be understood as the total number of transactions in the block, which can be limited according to actual needs. If the number of the first target transactions is greater than or equal to the threshold value of the number of block transactions, it means that the transactions in the read-write set table are sufficient for block packaging. In this case, it is only necessary to determine the transactions participating in the block packaging from the read-write set table. Such transactions are the second target transactions, and the number of the second target transactions is equal to the threshold value of the number of block transactions. The read-write set of the second target transaction is extracted from the read-write set table to obtain a read-write set sub-table. The read-write set sub-table includes the result obtained by the instant transaction data calculation of the embodiment of the present application, which is the result of streaming data preprocessing. This result and the transaction data of the second target transaction are used to generate a block. Since the result is generated in advance, the block generation speed is very fast, which reflects the speed-up effect of data preprocessing in the embodiment of the present application.

[0075] In one embodiment, when the block generation requirement is met, generating a block based on the transaction data of the first target transaction and the read-write set table includes: when the block generation requirement is met and the number of the first target transactions is less than the block transaction number threshold, determining a third target transaction participating in constituting the block, where the third target transaction is a transaction in the transaction pool for which transaction data calculation has not yet been performed; performing transaction data calculation on the third target transaction to obtain a transaction data calculation result; reading all data in the read-write set table and clearing the read-write set table; and generating a block based on the reading result, the transaction data calculation result, the transaction data corresponding to the first target transaction, and the transaction data of the third target transaction.

[0076] If the number of the first target transactions is less than the block transaction number threshold, it means that the transactions in the read-write set table may not be enough for block packaging, and it may be necessary to take out transactions (third target transactions) from the transaction pool that have not yet executed transaction data calculation. The number of third target transactions plus the number of first target transactions is equal to the block transaction number threshold. Transaction data calculation is performed on the transaction data of the third target transaction to obtain a calculation result. The calculation result and the transaction data of the third target transaction are information related to the third target transaction that needs to be packaged, while the transaction data corresponding to the first target transaction and the information of the read-write set table read before clearing are information related to the first target transaction that needs to be packaged. These two parts of information are packaged to generate a block. This situation is compatible with the technical solution of reading the transaction data in the transaction pool for calculation and generating blocks according to the calculation results in the related technology, which improves the compatibility of the embodiments of the present application.

[0077] In order to enable the target node to accelerate the block verification process based on the read-write set table maintained by itself, the target node of the embodiment of the present application also maintains a read transaction table and a write transaction table, both of which are used to assist in executing the process of accelerating block verification based on the read-write set table.

[0078] In one embodiment, the above method includes: updating a read transaction table based on the above read-write set, the above read transaction table recording the correspondence between the transaction identifier of the above first target transaction and the read set key, and the above read set key pointing to the unique read set of the unique transaction; updating a write transaction table based on the above read-write set, the above write transaction table recording the correspondence between the transaction identifier of the above first target transaction and the write set key, and the above write set key pointing to the unique write set of the unique transaction; wherein the above read transaction table and the above write transaction table are used to perform block verification on the blocks sent to the above target node.

[0079] Please refer to Table 1 and Table 2, which respectively show the contents of the read transaction table and the write transaction table.

[0080] Table 1

[0081] Read set key (read key) Transaction ID key0 1 key2 2 key12 3 key4 4 key8 5 key9 6

[0082] Table 2

[0083]

[0084]

[0085] After a transaction request is processed and a read-write set is generated, the read transaction table and write transaction table are modified accordingly. That is, the target node maintains three tables: the read-write set table, the read transaction table, and the write transaction table. See Table 3 for an example of the read-write set table.

[0086] Table 3

[0087] Transaction ID Reading Collection Writing Collection 1 [key0] [{key1,value1}] 2 [key2] [{key2,value2}] 3 [key12] [{key11,value11}] 4 [key4] [{key10,value10}] 5 [key8] [{key5,value5}] 6 [key9] [{key7,value7}]

[0088] A read-write set is a general term for write sets and read sets. A write set includes a write set key and its corresponding value, which represents the content written by the write set's write operation. Both read sets and write sets are common blockchain concepts and will not be discussed further. The contents of Tables 1, 2, and 3 in the examples of this application are related and consistent.

[0089] The embodiment of the present application does not limit the specific implementation of the update operation for the read transaction table and the write transaction table. In one embodiment, the method further includes traversing the records in the read-write set.

[0090] The above-mentioned updating of the read transaction table based on the above-mentioned read-write set includes: when the above-mentioned record is a read set and the read set key corresponding to the above-mentioned read set does not exist in the above-mentioned read transaction table, adding the record corresponding to the above-mentioned read set to the above-mentioned read transaction table; when the above-mentioned record is a read set and the read set key corresponding to the above-mentioned read set exists in the above-mentioned read transaction table, adding the above-mentioned transaction identifier corresponding to the above-mentioned read-write set to the record corresponding to the above-mentioned read set key.

[0091] The above-mentioned updating of the write transaction table based on the above-mentioned read-write set includes: when the above-mentioned record is a write set and the write set key corresponding to the above-mentioned write set does not exist in the above-mentioned write transaction table, adding the record corresponding to the above-mentioned write set to the above-mentioned write transaction table; when the above-mentioned record is a write set and the write set key corresponding to the above-mentioned write set exists in the above-mentioned write transaction table, adding the above-mentioned transaction identifier corresponding to the above-mentioned read-write set to the record corresponding to the above-mentioned write set key.

[0092] In one embodiment, the method further includes: upon receiving a block, verifying the block based on the read-write set table, the read transaction table, and the write transaction table. The method by which the target node performs block verification differs from related technologies. Since related technologies do not maintain the read-write set table, the read transaction table, and the write transaction table, verification can only be achieved by re-executing each transaction in the block. However, in the embodiment of the present application, since the target node maintains the read-write set table, the read transaction table, and the write transaction table, the verification process can be accelerated based on these three tables, and verification can be performed directly without calculating the transactions related to these three tables.

[0093] During block verification, the received block is parsed to obtain a transaction sequence formed by the fourth target transaction, which is the transaction within the block. In the embodiments of the present application, the fourth target transaction refers to the transaction within the block obtained by parsing the received block. Since transactions have transaction times, the transaction sequence is obtained by sorting them in chronological order. When the target node verifies the block, it acts as a slave node with respect to the block. When the target node packages the block, it acts as a master node with respect to the packaged block.

[0094] If all the fourth target transactions are verified, the block is deemed to have passed verification. Of course, if any of the fourth target transactions is not verified, the block cannot pass verification.

[0095] In the embodiment of the present application, the verification method for any fourth target transaction can be the same, and the fifth target transaction is taken as an example for detailed description. The fifth target transaction refers to any fourth target transaction. Figure 4 , which shows a flowchart of the fifth target transaction verification method in the embodiment of the present application. The above verification process includes:

[0096] S401. When the transaction identifier of the fifth target transaction exists in the read-write set table, extract the read-write set corresponding to the transaction identifier from the read-write set table.

[0097] If the transaction identifier of the fifth target transaction exists in the read-write set table, it means that the fifth target transaction has also been sent to the target node for transaction data calculation. In this case, the calculation result can be directly extracted without recalculating it as in the related art.

[0098] S402. When the extraction result is consistent with the read-write set corresponding to the transaction identifier in the block, it is determined that the fifth target transaction verification has passed.

[0099] Of course, if the extraction result is inconsistent with the read-write set corresponding to the above transaction identifier in the above block, the fifth target transaction verification fails, the block verification also fails, and there is no need to execute the subsequent process.

[0100] S403: Delete the record corresponding to the transaction identifier of the fifth target transaction in the read-write set table, the read transaction table, and the write transaction table.

[0101] Regardless of whether the extraction result is consistent with the read-write set corresponding to the transaction identifier in the block, step S403 is executed. Because the fifth target transaction has already been recorded in the block currently being verified, the target node does not need to repack it into the block. The contents of the read-write set table are the basis for the target node to pack the block. To avoid repackaging, the record corresponding to the transaction identifier of the fifth target transaction in the read-write set table, the read transaction table, and the write transaction table is deleted.

[0102] S404. If the transaction identifier of the fifth target transaction does not exist in the read-write set table, calculate transaction data for the fifth target transaction to obtain a corresponding read-write set.

[0103] If the transaction identifier of the fifth target transaction does not exist in the read-write set table, it means that the fifth target transaction has not been sent to the target node for transaction data calculation, and then recalculation is required. The present embodiment does not limit the calculation method, for example, calculation can be performed by a virtual machine.

[0104] S405. When the calculated read-write set is consistent with the read-write set corresponding to the transaction identifier in the block, it is determined that the fifth target transaction verification has passed.

[0105] Of course, if the calculated read-write set is inconsistent with the read-write set corresponding to the transaction identifier in the block, the fifth target transaction fails to be verified, and the block also fails to be verified, and there is no need to execute subsequent processes.

[0106] In the execution branch corresponding to S404, there is also concurrent conflict resolution logic. Figure 5 A flowchart of the concurrency conflict resolution logic of this embodiment of the present application is shown. The execution logic includes the following steps S501 and S502:

[0107] S501. Traverse the read set in the above read-write set, and perform the following operations based on the read read set: if the read set key corresponding to the above read set exists in the above write transaction table, obtain the transaction identification list corresponding to the above read set key; delete the records corresponding to the above transaction identification list in the above read-write set table, the above write transaction table and the above read transaction table.

[0108] S501. Traverse the write sets in the above read-write set, and perform the following operations based on the read write set: if the write set key corresponding to the above write set exists in the above read transaction table, obtain the transaction identifier list corresponding to the above write set key; and delete the records corresponding to the above transaction identifier list in the above read-write set table, the above write transaction table and the above read transaction table.

[0109] The purpose of executing S501 and S502 is to eliminate concurrency conflicts. In the embodiment of the present application, if the read set key of the read set in the newly generated read-write set is the same as the write set key in the already generated write transaction table, or if the write set key of the write set in the newly generated read-write set is the same as the read set key in the already generated read transaction table, it can be considered that a concurrency conflict has occurred. If a concurrency conflict occurs, the relevant records causing the conflict need to be deleted.

[0110] Please refer to Figure 6 , which shows a schematic diagram of the logical structure of the target node in an embodiment of the present application. The target node includes the following logical modules:

[0111] Network Module 601: The network module 601 is responsible for communication between the target node and other nodes in the blockchain system, including receiving and sending transactions, blocks, consensus messages, etc. The network module 601 ensures smooth information transmission between nodes and maintains the normal operation of the entire blockchain system.

[0112] Verification Module 602: Verification Module 602 is responsible for verifying received transactions and includes two submodules: Certificate Verification Module 6021 and Authority Verification Module 6022. Certificate Verification Module 6021 verifies the identity of the transaction initiator, ensuring they possess a valid certificate and signature. Authority Verification Module 6022 verifies the transaction initiator's authority to execute the transaction, preventing unauthorized responses.

[0113] Transaction pool module 603: The transaction pool module 603 is responsible for storing transaction data for transactions that have not yet been included in the block. When a new transaction passes the verification module 602, it will enter the transaction pool 603 and wait to be included in the block.

[0114] Scheduling, Execution, and Verification Module 604: Responsible for managing streaming data processing functions, it is the core module for executing the data processing solution in the embodiments of this application and is a module not found in related technologies. Scheduling, Execution, and Verification Module 604 includes the following submodules: Read / Write Transaction Table Management Module 6041: Manages the read and write transaction tables. Read / Write Set Table Management Module 6042: Manages the read / write set tables.

[0115] Block transaction validator 605: responsible for verifying whether the transactions in the block comply with the rules and constraints.

[0116] Block transaction packager 606: responsible for selecting transactions from the transaction pool and packaging them into new blocks.

[0117] Virtual machine engine 607: responsible for calculating transaction data and generating transaction read and write sets.

[0118] Block Generator 608: Responsible for generating new blocks, including transaction packaging, generating block header information, etc.

[0119] Consensus Module 609: Responsible for reaching consensus among blockchain nodes to determine a unique version of the blockchain. Consensus Module 609 ensures the security and decentralization of the blockchain system through a specific consensus algorithm.

[0120] Data Management Module 6010: Responsible for managing the data in the target node, it includes two submodules: Blockchain Ledger Management Module 6011 and State Data Management Module 6012. Blockchain Ledger Management Module 6011: Manages confirmed block data and records all transaction information in the blockchain system. State Data Management Module 6012: Manages the state data of the target node in the blockchain system, such as account balances and smart contract status.

[0121] Please refer to Figure 7 , which shows a flow chart of a method for a target node to perform streaming data processing in a specific implementation of an embodiment of the present application. Streaming data processing refers to a data preprocessing solution that processes relevant transaction data immediately after receiving a transaction request, without waiting for block packaging. Streaming data processing includes the following steps:

[0122] 7001. Start.

[0123] 7002. The account that needs to conduct a transaction initiates a transaction request.

[0124] 7003. The account signs the request content of the above transaction request.

[0125] 7004. The account sends the above request content and signature to the target node.

[0126] 7005. The network module 601 of the target node receives the request.

[0127] 7006. The certificate verification module 6021 of the target node performs certificate and signature verification on the request and determines whether the verification is successful. If so, the process goes to 7008; otherwise, the process goes to 7007.

[0128] 7007. Returns the signature verification failure result. Go to 7023.

[0129] 7008. The target node's authority verification module 6022 performs authority verification on the request. If the verification is successful, go to 7010; otherwise, go to 7009.

[0130] 7009. Returns the result of permission verification failure. Go to 7023.

[0131] 7010. The above transaction enters the transaction pool.

[0132] 7011. The scheduling execution and verification module 604 of the target node immediately executes the above transaction and records the current block height.

[0133] 7012. The scheduling execution and verification module 604 records the execution results of the above transactions and generates a read-write set.

[0134] 7013. The scheduling execution and verification module 604 puts the transaction identifier and the corresponding read-write set into the read-write table set.

[0135] 7014. The scheduling execution and verification module 604 traverses the read-write set of the above transaction.

[0136] 7015. Is the current set a read set? If so, go to 7016; otherwise, go to 7019.

[0137] 7016. Does the read set key for the read set exist in the read transaction table? If so, go to 7018; otherwise, go to 7017.

[0138] 7017. Create a new record in the read transaction table.

[0139] 7018. Append the transaction identifier of the above transaction to the record corresponding to the above read set key in the read transaction table.

[0140] 7019. The current write set is in the write transaction table. Does the write set key match the read set key in the previous example? If so, proceed to 7021; otherwise, proceed to 7020.

[0141] 7020. Create a new record in the write transaction table.

[0142] 7021. Append the transaction identifier of the above transaction to the record corresponding to the above write set key in the write transaction table.

[0143] 7022. Is the traversal complete? If yes, go to 7023; otherwise, go to 7014.

[0144] 7023. End.

[0145] Please refer to Figure 8 , which shows a flowchart of a target node performing block verification in a specific implementation of an embodiment of the present application. The block verification includes the following steps:

[0146] 8001. Start.

[0147] 8002. The target node receives the block to be verified.

[0148] 8003. The target node parses all transactions in the block to be verified.

[0149] 8004. The block transaction validator 605 traverses the transactions in sequence and prepares to perform transaction verification.

[0150] 8005. Does the read / write set table contain the transaction identifier of the current transaction? If so, go to 8006; otherwise, go to 8007.

[0151] 8006. Delete the transaction identifier from the read-write set table, read transaction table, and write transaction table. Go to 8009.

[0152] 8007. Start the virtual machine engine 607 to execute the current transaction.

[0153] 8008. The virtual machine engine 607 generates a read-write set.

[0154] 8009. Are the read / write sets completely consistent with the contents of the block? If so, go to 8010; otherwise, go to 8028.

[0155] 8010. The transaction was successfully verified.

[0156] 8011. Traverse the read set keys of the read set of this read-write set.

[0157] 8012. Does the write transaction table contain a write set key that is identical to the read set key? If so, go to 8013; otherwise, go to 8017.

[0158] 8013. Obtain a list of transaction identifiers corresponding to the write set key in the write transaction table.

[0159] 8014. Delete the records corresponding to the above list in the read-write set table.

[0160] 8015. Delete the records corresponding to the above list in the read transaction table.

[0161] Deleting the records corresponding to the above list in the read transaction table refers to deleting the records corresponding to the read set keys corresponding to the above list in the read transaction table.

[0162] 8016. Delete the records corresponding to the above list in the write transaction table.

[0163] Deleting the records corresponding to the above list in the write transaction table refers to deleting the records corresponding to the write set keys corresponding to the above list in the write transaction table.

[0164] 8017. Is the read set traversal complete? If yes, go to 8018; otherwise, go to 8011.

[0165] 8018. Traverse the write set keys of the write set of this read-write set.

[0166] 8019. Does the read transaction table have a read set key that is identical to the write set key? If so, go to 8020; otherwise, go to 8024.

[0167] 8020. Obtain a list of transaction identifiers corresponding to the read set key in the read transaction table.

[0168] 8021. Delete the records corresponding to the above list in the read-write set table.

[0169] 8022. Delete the records corresponding to the above list in the read transaction table.

[0170] Deleting the records corresponding to the above list in the read transaction table refers to deleting the records corresponding to the read set keys corresponding to the above list in the read transaction table.

[0171] 8023. Delete the records corresponding to the above list in the write transaction table.

[0172] Deleting the records corresponding to the above list in the write transaction table refers to deleting the records corresponding to the write set keys corresponding to the above list in the write transaction table.

[0173] 8024. Is the write set traversal complete? If yes, go to 8025; otherwise, go to 8018.

[0174] 8025. Are all transactions verified? If yes, go to 8026; otherwise, go to 8004.

[0175] 8026. The target node appends the block to the blockchain ledger.

[0176] 8027. The target node updates the status database.

[0177] 8028. End.

[0178] During the block verification process, the read-write set corresponding to the transaction that has not been pre-calculated is calculated by the virtual machine engine. By traversing the read-write set, read-write conflicts or write-read conflicts can be found in time. In the embodiment of the present application, these conflicts are collectively referred to as concurrency conflicts. Steps S8014 to S8016 resolve read-write conflicts, and steps S8021 to S8023 resolve write-read conflicts. If a concurrency conflict occurs, it is necessary to follow Figure 8 To facilitate understanding of concurrency conflicts, the present application provides Table 4, which shows a partial example of a read-write set table. In Table 4, the key of the read set portion is the read set key, and the key of the write set portion is the write set key.

[0179] Table 4

[0180]

[0181]

[0182] The embodiment of the present application proposes that if the read set of transaction A and the write set of transaction B have the same key, that is, the read set key of the read set of transaction A is the same as the write set key of the write set of transaction B, then there is a conflict, otherwise there is no conflict. Transaction A and transaction B generally refer to two different transactions. For example, if there are other transaction identifiers besides transaction identifier 25, and the other transaction identifiers correspond to the read set key key0. According to Table 4, it can be seen that the read set key key0 is the write set key corresponding to transaction identifier 25. In this case, it can be determined that a conflict has occurred, and the relevant records of transaction identifier 25 in the read-write table set, read transaction table, and write transaction table are deleted.

[0183] Please refer to Figure 9 , which shows a schematic diagram of the process of block packaging by the target node in a specific implementation of the embodiment of the present application. The block packaging includes the following steps:

[0184] 9001. Start.

[0185] 9002. The scheduling execution and verification module 604 of the target node prepares to generate a block.

[0186] 9003. Block transaction packager 606 checks whether the number of transactions in the read / write set table has reached the block generation threshold. If yes, go to 9008; otherwise, go to 9004.

[0187] 9004. The block transaction packager 606 obtains all data from the read-write set table.

[0188] 9005. The block transaction packager 606 obtains the remaining transactions from the transaction pool.

[0189] 9006. The virtual machine engine 607 executes the remaining transactions obtained from the transaction pool.

[0190] 9007. The block generator 608 packages the transaction execution result and the read-write set table reading result into a block to be verified. Go to 9010.

[0191] 9008. The block transaction packager 606 reads the transactions to be packaged from the read-write set table.

[0192] 9009. The block generator 608 packages the above transactions into blocks to be verified.

[0193] 9010. Distribute the blocks to be verified to the slave nodes for verification.

[0194] 9011. End.

[0195] Please refer to Figure 10 , which shows a flow chart of data processing by the target node provided by the embodiment of the present application. Different transactions can be sent to any node in the blockchain system and pre-processed immediately through streaming computing. The read-write sets generated by the pre-processing will be temporarily stored in the read-write set table maintained by the node executing the streaming computing itself, and can be packaged into the block when the node is packaged. The embodiment of the present application compares the proposed data processing scheme with the transaction data processing scheme in the related art as follows:

[0196] Disadvantages of transaction data processing solutions using related technologies:

[0197] 1. Limited Performance: In traditional blockchains, there is a dependency between master and slave nodes. Slave nodes can only complete block verification by recalculating transactions in blocks sent by the master node. They cannot immediately calculate transactions upon receipt. Furthermore, master nodes only calculate transactions when blocks are packaged, and cannot calculate transactions at any time. As a result, both master and slave nodes are often in a waiting state, unable to fully utilize their CPU and memory resources, limiting the performance of blockchain systems.

[0198] 2. Low verification efficiency: When verifying blocks in traditional solutions, slave nodes need to re-execute transactions to verify the correctness of transaction results. This will lead to a large amount of computational redundancy, reduce the verification efficiency of the blockchain system, and affect the performance of the entire blockchain system.

[0199] Advantages of the data processing solution proposed in the embodiment of this application:

[0200] 1. A verifiable blockchain transaction result storage data structure was designed. Each node maintains three tables: a read-write set table, a read transaction table, and a write transaction table. These three tables work together to cache transaction results and verify the read-write set. By computing transactions in real-time streaming and temporarily storing the results in the read-write set table, transactions can be accessed and computed at any time, reducing wait times between master and slave nodes and maximizing blockchain performance.

[0201] 2. Conflict resolution based on read-write set feedback. During block verification, read-write conflicts or write-read conflicts are promptly detected based on the read and write transaction tables. These conflicts are resolved and updated in real time to ensure the real-time accuracy of all transaction results. When verifying a block, slave nodes can verify based on pre-calculated read-write set tables, reducing transaction computations and significantly improving the verification efficiency of the blockchain system. This reduces computational redundancy between nodes and enhances the performance of the entire blockchain system. This approach also enhances the validity of transaction results, ensuring the security and stability of the blockchain system.

[0202] 3. The embodiment of the present application can make the CPU of the master and slave nodes almost fully loaded by reducing the waiting time of the master and slave nodes, thereby maximizing performance.

[0203] 4. Enhanced security and stability: By updating the read-write set table, read transaction table, and write transaction table in real time, conflicts can be handled in real time, improving the performance of the entire blockchain system. It also ensures the security and stability of the blockchain system, making the blockchain system have higher reliability while having high performance.

[0204] The data processing solution provided in the embodiments of the present application can be widely applied in various application scenarios. The following are examples of application scenarios:

[0205] 1. High-performance financial transaction systems: Financial transaction systems typically need to process large volumes of real-time transactions and require a high degree of security and stability. The streaming, verifiable blockchain transaction data processing solution of the present application embodiment can significantly improve the performance and verification efficiency of blockchain systems, enabling them to meet the high throughput and low latency requirements of financial transaction systems.

[0206] 2. IoT device data sharing and management scenarios: IoT devices generate massive amounts of data that requires real-time processing. The high performance of the present embodiment makes it suitable for real-time sharing and management of IoT device data, ensuring data security, reliability, and real-time performance. Furthermore, the streaming, verifiable blockchain transaction data processing solution of the present embodiment enables timely conflict resolution and improved stability.

[0207] 3. Cross-chain Transaction and Asset Management Scenarios: In the blockchain industry, cross-chain technology and asset management scenarios require processing a large number of real-time transactions while ensuring transaction security and consistency. The streaming, verifiable blockchain transaction data processing solution of the present embodiment can improve the performance of cross-chain transaction and asset management systems, achieving higher transaction throughput and lower latency, thereby meeting the needs of cross-chain transaction and asset management.

[0208] 4. Supply Chain Management and Traceability Scenarios: In supply chain management and traceability scenarios, real-time data processing and ensuring data security and accuracy are crucial. The streaming, verifiable blockchain transaction data processing solution of the present embodiment can improve the performance of supply chain management systems, achieving higher data processing capabilities, lower latency, and improved stability.

[0209] 5. Permission Control and Data Privacy Protection Scenarios: In applications involving permission control and data privacy protection, the high-performance streaming verifiable blockchain transaction data processing solution of the present application embodiment enables real-time permission verification and data protection. Furthermore, timely conflict resolution ensures data security and stability, meeting the requirements of permission control and data privacy protection.

[0210] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0211] Please refer to Figure 11 , which shows a block diagram of a data processing device applied to a blockchain according to one embodiment of the present application. The device is applied to a target node, which is any node in the blockchain system. The device may include:

[0212] Transaction request response module 1101 is configured to respond to a transaction request by calculating a read-write set corresponding to a transaction identifier in the transaction request based on the transaction data corresponding to the transaction identifier; and adding the read-write set to a read-write set table, which is configured to record an association between the transaction identifier of a first target transaction and the read-write set corresponding to the transaction identifier. The first target transaction is a transaction processed by the target node but not yet solidified in a block by the target node.

[0213] The block generation module 1102 is configured to generate a block based on the transaction data of the first target transaction and the read-write set table when the block generation requirements are met.

[0214] In one embodiment, the transaction request response module 1101 is configured to perform the following operations:

[0215] Based on the read-write set, a read transaction table is updated. The read transaction table records the correspondence between the transaction identifier of the first target transaction and the read set key. The read set key points to a unique read set of a unique transaction.

[0216] Based on the read-write set, a write transaction table is updated. The write transaction table records the correspondence between the transaction identifier of the first target transaction and the write set key. The write set key points to a unique write set of a unique transaction.

[0217] The read transaction table and the write transaction table are used to verify the blocks sent to the target node.

[0218] In one embodiment, the transaction request response module 1101 is configured to perform the following operations:

[0219] Traverse the records in the above read-write set;

[0220] If the record is a read set and the read set key corresponding to the read set does not exist in the read transaction table, add the record corresponding to the read set to the read transaction table; if the record is a read set and the read set key corresponding to the read set exists in the read transaction table, add the transaction identifier corresponding to the read-write set to the record corresponding to the read set key;

[0221] If the above record is a write set and the write set key corresponding to the write set does not exist in the above write transaction table, the record corresponding to the write set is added to the above write transaction table; if the above record is a write set and the write set key corresponding to the write set exists in the above write transaction table, the transaction identifier corresponding to the read-write set is added to the record corresponding to the write set key.

[0222] In one embodiment, the block generation module 1102 is configured to perform the following operations:

[0223] If the block generation requirements are met and the number of the first target transactions is greater than or equal to the block transaction number threshold, determining a second target transaction, where the second target transaction is the first target transaction that participates in forming the block;

[0224] Reading the read-write set sub-table corresponding to the second target transaction in the read-write set table, and deleting the read-write set sub-table in the read-write set table;

[0225] A block is generated based on the read result and the transaction data corresponding to the second target transaction.

[0226] In one embodiment, the block generation module 1102 is configured to perform the following operations:

[0227] If the block generation requirements are met and the number of the first target transactions is less than the block transaction number threshold, a third target transaction is determined to participate in forming the block. The third target transaction is a transaction in the transaction pool for which transaction data calculation has not yet been performed.

[0228] Performing transaction data calculation on the third target transaction to obtain a transaction data calculation result;

[0229] Read all the data in the read-write set table and clear the read-write set table;

[0230] A block is generated based on the reading result, the transaction data calculation result, the transaction data corresponding to the first target transaction, and the transaction data of the third target transaction.

[0231] In one embodiment, the apparatus further includes a block verification module 1103 configured to perform the following operations:

[0232] When a block is received, the block is verified based on the read-write set table, the read transaction table, and the write transaction table.

[0233] In one embodiment, the block verification module 1103 is configured to perform the following operations:

[0234] Parsing the block to obtain a transaction sequence formed by a fourth target transaction, where the fourth target transaction is a transaction in the block;

[0235] If all of the fourth target transactions are verified successfully, determining that the block has passed verification;

[0236] The method further includes performing a verification operation on a fifth target transaction, where the fifth target transaction is any transaction in the transaction sequence, and the verification operation includes:

[0237] If the transaction identifier of the fifth target transaction exists in the read-write set table, extracting the read-write set corresponding to the transaction identifier from the read-write set table;

[0238] If the extraction result is consistent with the read-write set corresponding to the transaction identifier in the block, the fifth target transaction is determined to have passed verification;

[0239] Delete the record corresponding to the transaction identifier of the fifth target transaction in the read-write set table, the read transaction table, and the write transaction table.

[0240] In one embodiment, the block verification module 1103 is configured to perform the following operations:

[0241] If the transaction identifier of the fifth target transaction does not exist in the read-write set table, performing transaction data calculation on the fifth target transaction to obtain a corresponding read-write set;

[0242] When the calculated read-write set is consistent with the read-write set corresponding to the transaction identifier in the block, it is determined that the fifth target transaction verification has passed.

[0243] In one embodiment, the block verification module 1103 is configured to perform the following operations:

[0244] Traverse the read sets in the above read-write set and perform the following operations based on the read read sets:

[0245] If a read set key corresponding to the read set exists in the write transaction table, a transaction identification list corresponding to the read set key is obtained; and records corresponding to the transaction identification list are deleted from the read-write set table, the write transaction table, and the read transaction table.

[0246] In one embodiment, the block verification module 1103 is configured to perform the following operations:

[0247] Traverse the write sets in the above read-write set and perform the following operations based on the read write sets:

[0248] If the write set key corresponding to the write set exists in the read transaction table, a transaction identifier list corresponding to the write set key is obtained; and records corresponding to the transaction identifier list are deleted from the read-write set table, the write transaction table, and the read transaction table.

[0249] It should be noted that the apparatus provided in the above embodiments, when implementing its functions, is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0250] Please refer to Figure 12 , which shows a block diagram of a computer device provided by one embodiment of the present application. The computer device may be a server for executing the above-mentioned data processing method applied to blockchain.

[0251] Specifically:

[0252] Computer device 1200 includes a central processing unit (CPU) 1201, a system memory 1204 including a random access memory (RAM) 1202 and a read-only memory (ROM) 1203, and a system bus 1205 connecting system memory 1204 and CPU 1201. Computer device 1200 also includes a basic input / output system (I / O system) 1206 that facilitates information transfer between various components within the computer, and a mass storage device 1207 for storing an operating system 1213, application programs 1214, and other program modules 1215.

[0253] The basic input / output system 1206 includes a display 1208 for displaying information and an input device 1209, such as a mouse and keyboard, for user input. Both the display 1208 and the input device 1209 are connected to the central processing unit 1201 via an input / output controller 1210 connected to the system bus 1205. The basic input / output system 1206 may also include an input / output controller 1210 for receiving and processing input from a variety of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 1210 also provides output to a display screen, printer, or other types of output devices.

[0254] The mass storage device 1207 is connected to the central processing unit 1201 via a mass storage controller (not shown) connected to the system bus 1205. The mass storage device 1207 and its associated computer-readable media provide non-volatile storage for the computer device 1200. In other words, the mass storage device 1207 may include computer-readable media (not shown) such as a hard disk or a CD-ROM (Compact Disc Read-Only Memory) drive.

[0255] Without loss of generality, computer-readable media may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc) or other optical storage, tape cassettes, magnetic tape, disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that computer storage media are not limited to the above-mentioned ones. The above-mentioned system memory 1204 and mass storage device 1207 can be collectively referred to as memory.

[0256] According to various embodiments of the present application, the computer device 1200 may also be connected to a remote computer on a network such as the Internet for operation. That is, the computer device 1200 may be connected to the network 1212 via the network interface unit 1211 connected to the system bus 1205, or the network interface unit 1211 may be used to connect to other types of networks or remote computer systems (not shown).

[0257] The above-mentioned memory also includes a computer program, which is stored in the memory and configured to be executed by one or more processors to implement the above-mentioned data processing method applied to blockchain.

[0258] In an exemplary embodiment, a computer-readable storage medium is further provided, wherein the storage medium stores at least one instruction, at least one program, a code set, or an instruction set. When the at least one instruction, the at least one program, the code set, or the instruction set is executed by a processor, the data processing method applied to the blockchain is implemented.

[0259] Specifically, the data processing method applied to the blockchain is applied to a target node, which is any node in the blockchain system. The method includes:

[0260] In response to a transaction request, calculating a read-write set corresponding to the transaction identifier based on transaction data corresponding to the transaction identifier in the transaction request;

[0261] Adding the read-write set to a read-write set table, which records the association between the transaction identifier of a first target transaction and the read-write set corresponding to the transaction identifier. The first target transaction is a transaction that has been processed by the target node but has not yet been solidified in a block by the target node.

[0262] When the block generation requirements are met, a block is generated based on the transaction data of the first target transaction and the read-write set table.

[0263] In one embodiment, the above method further comprises:

[0264] Based on the read-write set, a read transaction table is updated. The read transaction table records the correspondence between the transaction identifier of the first target transaction and the read set key. The read set key points to a unique read set of a unique transaction.

[0265] Based on the read-write set, a write transaction table is updated. The write transaction table records the correspondence between the transaction identifier of the first target transaction and the write set key. The write set key points to a unique write set of a unique transaction.

[0266] The read transaction table and the write transaction table are used to verify the blocks sent to the target node.

[0267] In one embodiment, the method further includes traversing the records in the read-write set;

[0268] Updating the read transaction table based on the read-write set includes: if the record is a read set and the read set key corresponding to the read set does not exist in the read transaction table, adding a record corresponding to the read set to the read transaction table; if the record is a read set and the read set key corresponding to the read set exists in the read transaction table, adding the transaction identifier corresponding to the read-write set to the record corresponding to the read set key;

[0269] The above-mentioned updating of the write transaction table based on the above-mentioned read-write set includes: when the above-mentioned record is a write set and the write set key corresponding to the above-mentioned write set does not exist in the above-mentioned write transaction table, adding the record corresponding to the above-mentioned write set to the above-mentioned write transaction table; when the above-mentioned record is a write set and the write set key corresponding to the above-mentioned write set exists in the above-mentioned write transaction table, adding the above-mentioned transaction identifier corresponding to the above-mentioned read-write set to the record corresponding to the above-mentioned write set key.

[0270] In one embodiment, when the block generation requirements are met, generating a block based on the transaction data of the first target transaction and the read-write set table includes:

[0271] If the block generation requirements are met and the number of the first target transactions is greater than or equal to the block transaction number threshold, determining a second target transaction, where the second target transaction is the first target transaction that participates in forming the block;

[0272] Reading the read-write set sub-table corresponding to the second target transaction in the read-write set table, and deleting the read-write set sub-table in the read-write set table;

[0273] A block is generated based on the read result and the transaction data corresponding to the second target transaction.

[0274] In one embodiment, when the block generation requirements are met, generating a block based on the transaction data of the first target transaction and the read-write set table includes:

[0275] If the block generation requirements are met and the number of the first target transactions is less than the block transaction number threshold, a third target transaction is determined to participate in forming the block. The third target transaction is a transaction in the transaction pool for which transaction data calculation has not yet been performed.

[0276] Performing transaction data calculation on the third target transaction to obtain a transaction data calculation result;

[0277] Read all the data in the read-write set table and clear the read-write set table;

[0278] A block is generated based on the reading result, the transaction data calculation result, the transaction data corresponding to the first target transaction, and the transaction data of the third target transaction.

[0279] In one embodiment, the above method further comprises:

[0280] When a block is received, the block is verified based on the read-write set table, the read transaction table, and the write transaction table.

[0281] In one embodiment, verifying the block based on the read-write set table, the read transaction table, and the write transaction table includes:

[0282] Parsing the block to obtain a transaction sequence formed by a fourth target transaction, where the fourth target transaction is a transaction in the block;

[0283] If all of the fourth target transactions are verified successfully, determining that the block has passed verification;

[0284] The method further includes performing a verification operation on a fifth target transaction, where the fifth target transaction is any transaction in the transaction sequence, and the verification operation includes:

[0285] If the transaction identifier of the fifth target transaction exists in the read-write set table, extracting the read-write set corresponding to the transaction identifier from the read-write set table;

[0286] If the extraction result is consistent with the read-write set corresponding to the transaction identifier in the block, the fifth target transaction is determined to have passed verification;

[0287] Delete the record corresponding to the transaction identifier of the fifth target transaction in the read-write set table, the read transaction table, and the write transaction table.

[0288] In one embodiment, the verification operation further includes:

[0289] If the transaction identifier of the fifth target transaction does not exist in the read-write set table, performing transaction data calculation on the fifth target transaction to obtain a corresponding read-write set;

[0290] When the calculated read-write set is consistent with the read-write set corresponding to the transaction identifier in the block, it is determined that the fifth target transaction verification has passed.

[0291] In one embodiment, after calculating the transaction data for the fifth target transaction to obtain a corresponding read-write set, the verification operation further includes traversing the read set in the read-write set and performing the following operations based on the read read set:

[0292] If a read set key corresponding to the read set exists in the write transaction table, a transaction identification list corresponding to the read set key is obtained; and records corresponding to the transaction identification list are deleted from the read-write set table, the write transaction table, and the read transaction table.

[0293] In one embodiment, after calculating the transaction data for the fifth target transaction to obtain the corresponding read-write set, the verification operation further includes traversing the write sets in the read-write set and performing the following operations based on the read write sets:

[0294] If the write set key corresponding to the write set exists in the read transaction table, a transaction identifier list corresponding to the write set key is obtained; and records corresponding to the transaction identifier list are deleted from the read-write set table, the write transaction table, and the read transaction table.

[0295] Optionally, the computer-readable storage medium may include: ROM (Read Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or an optical disk, etc. Among them, the random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0296] In an exemplary embodiment, a computer program product or computer program is also provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned data processing method applied to a blockchain.

[0297] It should be understood that the "multiple" mentioned in this article refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent three situations: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship. In addition, the step numbers described in this article only illustrate a possible execution sequence between the steps. In some other embodiments, the above steps may not be executed in the order of the numbers, such as two steps with different numbers are executed at the same time, or two steps with different numbers are executed in the opposite order to the diagram. The embodiments of the present application do not limit this.

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

[0299] In addition, in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0300] The above are merely exemplary embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A data processing method applied to blockchain, characterized in that: Applied to a target node, where the target node is any node in a blockchain system, the method includes: In response to a transaction request, calculating a read-write set corresponding to the transaction identifier based on transaction data corresponding to the transaction identifier in the transaction request; Adding the read-write set to a read-write set table, where the read-write set table is used to record the association between the transaction identifier of a first target transaction and the read-write set corresponding to the transaction identifier, where the first target transaction is a transaction processed by the target node but not yet solidified in a block by the target node; When block generation requirements are met, a block is generated based on the transaction data of the first target transaction and the read-write set table.

2. The method according to claim 1, characterized in that The method further comprises: Update a read transaction table based on the read-write set, wherein the read transaction table records the correspondence between the transaction identifier of the first target transaction and a read set key, wherein the read set key points to a unique read set of a unique transaction; Updating a write transaction table based on the read-write set, wherein the write transaction table records a correspondence between a transaction identifier and a write set key of the first target transaction, wherein the write set key points to a unique write set of a unique transaction; The read transaction table and the write transaction table are used to perform block verification on the blocks sent to the target node.

3. The method according to claim 2, characterized in that The method further includes traversing the records in the read-write set; The updating of the read transaction table based on the read-write set includes: if the record is a read set and the read set key corresponding to the read set does not exist in the read transaction table, adding a record corresponding to the read set in the read transaction table; if the record is a read set and the read set key corresponding to the read set exists in the read transaction table, adding the transaction identifier corresponding to the read-write set in the record corresponding to the read set key; The updating of the write transaction table based on the read-write set includes: when the record is a write set and the write set key corresponding to the write set does not exist in the write transaction table, adding a record corresponding to the write set to the write transaction table; when the record is a write set and the write set key corresponding to the write set exists in the write transaction table, adding the transaction identifier corresponding to the read-write set to the record corresponding to the write set key.

4. The method according to any one of claims 1 to 3, characterized in that The step of generating a block based on the transaction data of the first target transaction and the read-write set table when the block generation requirement is met includes: When the block generation requirement is met and the number of the first target transactions is greater than or equal to a block transaction number threshold, determining a second target transaction, where the second target transaction is the first target transaction that participates in forming a block; Reading the read-write set sub-table corresponding to the second target transaction in the read-write set table, and deleting the read-write set sub-table in the read-write set table; A block is generated based on the read result and the transaction data corresponding to the second target transaction.

5. The method according to any one of claims 1 to 3, characterized in that The step of generating a block based on the transaction data of the first target transaction and the read-write set table when the block generation requirement is met includes: When the block generation requirement is met and the number of the first target transactions is less than the block transaction number threshold, determining a third target transaction to participate in forming the block, where the third target transaction is a transaction in the transaction pool for which transaction data calculation has not yet been performed; performing transaction data calculation on the third target transaction to obtain a transaction data calculation result; Read all data in the read-write set table and clear the read-write set table; A block is generated based on the reading result, the transaction data calculation result, the transaction data corresponding to the first target transaction, and the transaction data of the third target transaction.

6. The method according to claim 2, characterized in that The method further comprises: When a block is received, the block is verified based on the read-write set table, the read transaction table, and the write transaction table.

7. The method according to claim 6, characterized in that The verifying the block based on the read-write set table, the read transaction table, and the write transaction table includes: Parsing the block to obtain a transaction sequence formed by a fourth target transaction, where the fourth target transaction is a transaction in the block; If all the fourth target transactions are verified successfully, determining that the block has passed the verification; The method further includes performing a verification operation on a fifth target transaction, where the fifth target transaction is any transaction in the transaction sequence, and the verification operation includes: If the transaction identifier of the fifth target transaction exists in the read-write set table, extracting the read-write set corresponding to the transaction identifier from the read-write set table; If the extraction result is consistent with the read-write set corresponding to the transaction identifier in the block, determining that the fifth target transaction verification has passed; Delete the record corresponding to the transaction identifier of the fifth target transaction in the read-write set table, the read transaction table, and the write transaction table.

8. The method according to claim 7, characterized in that The verification operation further includes: If the transaction identifier of the fifth target transaction does not exist in the read-write set table, performing transaction data calculation on the fifth target transaction to obtain a corresponding read-write set; When the calculated read-write set is consistent with the read-write set corresponding to the transaction identifier in the block, it is determined that the fifth target transaction verification has passed.

9. The method according to claim 8, characterized in that After calculating the transaction data of the fifth target transaction to obtain a corresponding read-write set, the verification operation further includes traversing the read set in the read-write set and performing the following operations based on the read read set: If a read set key corresponding to the read set exists in the write transaction table, obtaining a transaction identifier list corresponding to the read set key; The records corresponding to the transaction identification list are deleted from the read-write set table, the write transaction table, and the read transaction table.

10. The method according to claim 8, characterized in that After calculating the transaction data of the fifth target transaction to obtain a corresponding read-write set, the verification operation further includes traversing the write sets in the read-write set and performing the following operations based on the read write sets: If a write set key corresponding to the write set exists in the read transaction table, obtaining a transaction identifier list corresponding to the write set key; The records corresponding to the transaction identification list are deleted from the read-write set table, the write transaction table, and the read transaction table.

11. A data processing device applied to blockchain, characterized in that: Applied to a target node, which is any node in a blockchain system, the device comprises: a transaction request response module, configured to, in response to a transaction request, calculate a read-write set corresponding to a transaction identifier in the transaction request based on transaction data corresponding to the transaction identifier; and add the read-write set to a read-write set table, the read-write set table being configured to record an association between the transaction identifier of a first target transaction and the read-write set corresponding to the transaction identifier, the first target transaction being a transaction processed by the target node but not yet solidified in a block by the target node; The block generation module is configured to generate a block based on the transaction data of the first target transaction and the read-write set table when a block generation requirement is met.

12. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the data processing method applied to a blockchain according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that The storage medium stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the data processing method applied to the blockchain according to any one of claims 1 to 10.

14. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes to implement the data processing method applied to blockchain according to any one of claims 1 to 10.

Images