Blockchain-based data processing method, device, equipment, and readable storage medium

Abstract

The present invention discloses a blockchain-based data processing method, apparatus, device, and readable storage medium. The method comprises: upon monitoring the start of execution of a target block, suspending processing of an access request queue for a blockchain account book; the access request queue includes a queue task request; the task type of the queue task request does not belong to a transaction execution type; obtaining an execution task request belonging to the transaction execution type, accessing the blockchain account book according to the execution task request, obtaining an execution access result, and executing the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block; upon monitoring the end of execution of the target block, continuing to traverse the access request queue and accessing the blockchain account book according to the queue task requests in the access request queue. The present invention can reduce the preemption of storage resources by various functions and improve blockchain performance.

Description

Technical Field

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

[0002] Blockchain is a novel application model for computer technologies, integrating distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It primarily organizes data in chronological order and encrypts it into a ledger, rendering it tamper-proof and forgery-proof. It also enables data verification, storage, and updates. Blockchain also enables encrypted data transmission, node identification, and secure access, making it an advanced distributed infrastructure. Currently, blockchain applications are increasing due to its immutability and authenticity.

[0003] Currently, blockchain networks built using some popular blockchain protocols typically rely on core nodes, or full nodes, to complete all functions required for transaction on-chain, such as transaction broadcasting, transaction signature verification, transaction weight verification, block packaging, block consensus, transaction execution, contract query, and ledger storage. Some of these functions, such as transaction weight verification, transaction execution, and contract query, require access to the blockchain ledger. In large-scale blockchain projects, such as tax blockchains, due to their broad reach and concentrated processing times, the blockchain network must process thousands of transactions on-chain within a single timeframe. Furthermore, different transactions require different functions, and with a large number of transactions requiring these functions concurrently, these functions, such as transaction weight verification, transaction execution, and contract query, preemptively access the blockchain ledger. The resulting conflicts and context switches can reduce the efficiency of core nodes, potentially preventing the smooth and efficient operation of all functions. Summary of the Invention

[0004] The embodiments of the present application provide a blockchain-based data processing method, apparatus, device, and readable storage medium, which can effectively reduce the preemption of storage resources by various functions and improve blockchain performance.

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

[0006] When the execution of the target block is detected, the processing of the access request queue for the blockchain ledger is suspended; the access request queue includes queue task requests; the task type of the queue task request does not belong to the transaction execution type;

[0007] Obtaining an execution task request of the transaction execution type, accessing the blockchain ledger according to the execution task request, obtaining the execution access result, and executing the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block;

[0008] When the target block execution is detected, continue to traverse the access request queue and request access to the blockchain ledger according to the queue task in the access request queue.

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

[0010] A first monitoring module is configured to suspend processing of an access request queue for the blockchain ledger upon monitoring the start of execution of a target block; the access request queue includes queue task requests; the task type of the queue task request does not belong to a transaction execution type;

[0011] The access module is used to obtain an execution task request belonging to the transaction execution type, access the blockchain ledger according to the execution task request, obtain the execution access result, and execute the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block;

[0012] The second monitoring module is used to continue traversing the access request queue when it monitors that the execution of the target block has ended, and access the blockchain ledger according to the queue task request in the access request queue.

[0013] The first monitoring module includes:

[0014] a processing request determination unit, configured to, when monitoring the start of execution of a target block, search for a queue task request being processed in the access request queue for the blockchain ledger, and determine the queue task request being processed as the target queue task request;

[0015] The pausing unit is used to suspend processing of the access request queue when the processing of the target queue task request is completed.

[0016] The second monitoring module includes:

[0017] The access monitoring unit is used to continue traversing the access request queue when it is monitored that the execution of the target block is completed and the access request queue is not updated;

[0018] A first ledger access unit, configured to access the blockchain ledger according to a queue task request in the access request queue;

[0019] The above-mentioned data processing device further includes:

[0020] A third monitoring module is configured to traverse and update the access request queue upon monitoring the completion of execution of the target block and an update of the access request queue; the updated access request queue is obtained based on the update of the access request queue, and the updated access request queue includes queue task requests and new task requests that do not belong to the transaction execution type;

[0021] The third monitoring module is further used to access the blockchain ledger according to the queue task request and the new task request in the update access request queue.

[0022] The data processing device further includes:

[0023] The queue update module is used to add the new task request to the end of the access request queue if a new task request that does not belong to the transaction execution type is received during the execution process of the target block, thereby obtaining an updated access request queue.

[0024] The number of queue task requests is M; the number of task types of the M queue task requests is at least two; M is a positive integer;

[0025] The second monitoring module includes:

[0026] A sorting unit is configured to, upon monitoring the completion of execution of a target block, continue to traverse the access request queue and sort M queue task requests according to the priorities of at least two task types;

[0027] The second ledger access unit is used to process the sorted M queue task requests in sequence, access the blockchain ledger according to the processed queue task requests, obtain the request access result, and process the task indicated by the processed queue task request according to the request access result.

[0028] The data processing device further includes:

[0029] The deleting module is used to delete the queue task request in the processing completion state from the access request queue when the task indicated by the queue task request being processed is completed.

[0030] The number of queue task requests is M; the task types of the M queue task requests include a first task type and a second task type; M is a positive integer;

[0031] The second monitoring module includes:

[0032] A first request acquisition unit is configured to, upon monitoring the completion of execution of a target block, continue to traverse the access request queue and sequentially acquire k queue task requests belonging to the first task type from the M queue task requests as k first queue task requests; k is a positive integer less than M;

[0033] A second request acquisition unit is configured to sequentially acquire s queue task requests belonging to a second task type from the M queue task requests as s second queue task requests; s is a positive integer less than M;

[0034] The third ledger access unit is configured to sort the k first-queue task requests and the s second-queue task requests according to the priorities corresponding to the first task type and the second task type, respectively, to obtain a pending task queue, and access the blockchain ledger according to the first-queue task requests and the second-queue task requests in the pending task queue.

[0035] Among them, the number of queue task requests is M; M is a positive integer;

[0036] The second monitoring module includes:

[0037] The waiting time determination unit is used to continue traversing the access request queue when monitoring the completion of the execution of the target block, and obtain the waiting processing time corresponding to each queue task request in the M queue task requests;

[0038] a priority determination unit, configured to sort the M queue task requests according to the priority corresponding to each queue task request;

[0039] The fourth ledger access unit is used to process the sorted M queue task requests in sequence and access the blockchain ledger according to the processed queue task requests.

[0040] The second monitoring module includes:

[0041] A third request acquisition unit is configured to, upon monitoring the completion of execution of the target block, continue to traverse the access request queue and acquire the target queue task request from the access request queue;

[0042] The fifth ledger access unit is configured to read the target transaction from the target task request if the task type of the target queue task request is a transaction weight verification type, and query the blockchain ledger based on the target transaction;

[0043] The fifth ledger access unit is further configured to determine that the access result corresponding to the target queue task request is a duplicate transaction result if transaction data identical to the target transaction is found in the blockchain ledger;

[0044] The fifth ledger access unit is further configured to determine that the access result corresponding to the target queue task request is a non-duplicate transaction result if transaction data identical to the target transaction is not found in the blockchain ledger.

[0045] The second monitoring module includes:

[0046] The fourth request acquisition unit is configured to, upon monitoring that the execution of the target block has ended, continue to traverse the access request queue and acquire the target queue task request from the access request queue;

[0047] The sixth ledger access unit is configured to read target contract information from the target queue task request if the task type of the target queue task request is a contract query type, query the blockchain ledger for contract data associated with the target contract information, and use the contract data as the access result corresponding to the target task request.

[0048] The second monitoring module includes:

[0049] a fifth request acquisition unit, configured to, upon monitoring the completion of execution of the target block, continue to traverse the access request queue and acquire the target queue task request from the access request queue;

[0050] The seventh ledger access unit is used to obtain the data to be uploaded to the chain according to the target queue task request if the task type of the target queue task request is the type of storage in the ledger, and store the data to be uploaded to the chain in the blockchain ledger.

[0051] On one hand, an embodiment of the present application provides a computer device, including: a processor, a memory, and a network interface;

[0052] The above-mentioned processor is connected to the above-mentioned memory and the above-mentioned network interface, wherein the above-mentioned network interface is used to provide a data communication network element, the above-mentioned memory is used to store a computer program, and the above-mentioned processor is used to call the above-mentioned computer program to execute the method in the embodiment of the present application.

[0053] On one hand, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. The computer program is suitable for being loaded by a processor and executing the method in the embodiment of the present application.

[0054] On the one hand, an embodiment of the present application provides a computer program product or a computer program, which 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 the method in the embodiment of the present application.

[0055] In an embodiment of the present application, when the execution of the target block is monitored, the access request queue for the blockchain account book can be suspended, and then an execution task request of the transaction execution type is obtained. The blockchain account book is accessed according to the execution task request, and the execution access result is obtained. The transaction in the target block is executed according to the execution access result. When the execution of the target block is monitored, the access request queue is continued to be traversed, and the blockchain account book is accessed according to the queue task request in the access request queue. Among them, the access request queue includes queue task requests whose task type does not belong to the transaction execution type; the execution task request is generated during the execution of the target block. Through the method provided in the embodiment of the present application, task requests of different task types are dispersed into different time periods for processing. That is, during the execution of the target block, only the execution task requests of the transaction execution type generated during the execution process are processed, and other queue task requests that do not belong to the transaction execution type are suspended. In the time period from the completion of the target block execution to the start of the new target block execution, other queue task requests that do not belong to the transaction execution type are continued to be processed, thereby improving the situation where multiple functions access the blockchain account book in parallel, effectively reducing the preemption of storage resources by each function, and improving the performance of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. 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.

[0057] Figure 1 This is a structural diagram of a blockchain node system provided by an embodiment of the present application;

[0058] Figure 2 This is a schematic diagram of a blockchain-based data processing scenario provided by an embodiment of the present application;

[0059] Figure 3 This is a flowchart of a blockchain-based data processing method provided in an embodiment of the present application;

[0060] Figure 4a This is a blockchain transaction processing sequence diagram provided by an embodiment of the present application;

[0061] Figure 4b This is a blockchain query processing sequence diagram provided by an embodiment of the present application;

[0062] Figure 4c This is a schematic diagram of a blockchain ledger call provided by an embodiment of the present application;

[0063] Figure 4d This is a schematic diagram of access time distribution provided by an embodiment of the present application;

[0064] Figure 5 This is a flowchart of a blockchain-based data processing method provided in an embodiment of the present application;

[0065] Figure 6 This is a flowchart of a blockchain-based data processing method provided in an embodiment of the present application;

[0066] Figure 7 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application;

[0067] Figure 8 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0069] Blockchain is a chained data structure based on blocks. Blocks use digital summaries to verify previously acquired transaction histories, making them suitable for the tamper-proof and scalable requirements of distributed ledgers. The term "blockchain" also refers to the distributed ledger technologies implemented by blockchain structures, including distributed consensus, privacy and security protections, peer-to-peer communication technologies, network protocols, and smart contracts. The goal of blockchain is to create a distributed data record book that only allows additions, not deletions. The underlying structure of this ledger is a linear linked list. This linked list consists of a series of "blocks," with successive blocks recording the hash values of previous blocks. The validity of each block (and the transactions within it) can be quickly verified by calculating the hash value. If a blockchain node in a blockchain network proposes to add a new block, the block must be confirmed through a consensus mechanism.

[0070] Among them, it can be understood that a block is a data packet that carries transaction data (i.e., transaction business) on the blockchain network. It is a data structure marked with a timestamp and a hash value of the previous block. The block is verified by the network's consensus mechanism and the transactions in the block are determined.

[0071] It's understood that a hash value, also known as an information characteristic value or eigenvalue, is generated by converting input data of any length into a cipher and producing a fixed output using a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way encryption function. In a blockchain, each block (except the initial block) contains the hash value of the previous block, which is called the parent block of the current block. The hash value is the core foundation and most important aspect of the potential of blockchain technology, preserving the authenticity of recorded and viewed data and the integrity of the blockchain as a whole.

[0072] It is understood that a blockchain system can include smart contracts. In a blockchain system, a smart contract can be understood as a code that can be understood and executed by each node (including consensus nodes) of the blockchain, which can execute arbitrary logic and obtain results. A user can call a smart contract deployed on the blockchain by initiating a transaction service request through a client. Subsequently, the service node on the blockchain can send the transaction service request to the consensus node, and each consensus node on the blockchain can run the smart contract separately. It should be understood that a blockchain can include one or more smart contracts, which can be distinguished by an identity document (ID) or name. The transaction service request initiated by the client can also carry the identification number or name of the smart contract to specify the smart contract that the blockchain needs to run. If the smart contract specified by the client is a contract that needs to read data, each consensus node will access the local ledger to read the data. Finally, each consensus node will verify whether the execution results are consistent with each other (that is, reach consensus). If they are consistent, the execution results can be stored in their respective local ledgers and returned to the client.

[0073] A blockchain network is usually composed of many blockchain nodes. Users interact with the blockchain through DApps (decentralized applications). That is, users can send transaction data (business requests) corresponding to transactions to the blockchain through DApps. The life cycle of a transaction usually includes:

[0074] Transaction generation: Users input parameters through the DApp, which packages them into transaction data and sends them to a blockchain node.

[0075] Transaction broadcast: The blockchain node broadcasts the received transaction data to the entire blockchain network.

[0076] Transaction verification: After receiving the transaction data, the blockchain node verifies the signature of the transaction data and checks for duplicate transactions in the ledger (DB). The transaction data that passes the verification enters the transaction pool.

[0077] Block Packaging: Block producers extract transaction data from the transaction pool, package it into a proposed block, and broadcast it to the blockchain network. Block producers are responsible for packaging proposed blocks in this round. The choice of block producers varies depending on the consensus algorithm, with common options including rotating block production and competitive computing.

[0078] Block verification: After receiving the proposed block, the blockchain node verifies the transaction data in it. If the transaction is already in the transaction pool, the verification passes. Otherwise, the transaction needs to be signed and checked for duplicates.

[0079] Block consensus: Blockchain nodes vote on the proposed blocks they receive based on the block verification results. When a blockchain node receives a majority of votes and meets the consensus conditions, it approves and begins submitting the proposed blocks.

[0080] Block execution: Execute the transaction data in the approved proposed block.

[0081] Deposit into the ledger: Store the proposed block, transaction data, and transaction execution results into the blockchain ledger.

[0082] See Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain node system provided by an embodiment of the present application. Figure 1 The illustrated blockchain node system may correspond to a blockchain network, which may include, but is not limited to, a blockchain network corresponding to a consortium chain. A blockchain node system refers to a system for data sharing between blockchain nodes. The blockchain node system may include multiple blockchain nodes, specifically including blockchain node 10a, blockchain node 10b, blockchain node 10c, blockchain node 10d, ..., and blockchain node 10n. During normal operation, each node may receive data sent from the outside world and perform block chain processing based on the received data. It may also transmit data to the outside world. To ensure data interoperability between nodes, data connections may exist between each node, for example, between blockchain node 10a and blockchain node 10b, between blockchain node 10a and blockchain node 10c, and between blockchain node 10b and blockchain node 10c.

[0083] It is understandable that data or blocks can be transferred between blockchain nodes through the above-mentioned data connection. The blockchain network can realize data connection between blockchain nodes based on node identification. Each blockchain node in the blockchain network has a corresponding node identification, and each of the above-mentioned blockchain nodes can store the node identifications of other blockchain nodes with which it is connected, so that the acquired data or generated blocks can be broadcast to other blockchain nodes based on the node identifications of other blockchain nodes. For example, the blockchain node 10a can maintain a node identification list as shown in Table 1, which stores the node names and node identifications of other nodes:

[0084] Table 1

[0085] Node Name Node ID Blockchain node 10a 117.114.151.174 Blockchain node 10b 117.116.189.145 Blockchain node 10b 117.114.151.183 Blockchain node 10b 117.117.125.169 … … Blockchain node 10b 117.116.189.125

[0086] The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify a node in a blockchain network. Table 1 uses IP addresses as an example. For example, blockchain node 10a can send information (e.g., a block) to blockchain node 10b using node identifier 117.116.189.145, and blockchain node 10b can determine that the information was sent by blockchain node 10a using node identifier 117.114.151.174.

[0087] In the blockchain, before a block is put on the chain, it must pass the consensus of the consensus nodes in the blockchain network. Only after the consensus is passed can the block be added to the blockchain. It is understandable that when the blockchain is used in some scenarios of government or commercial organizations, not all participating nodes in the blockchain (i.e., the blockchain nodes in the above blockchain node system) have sufficient resources and necessity to become consensus nodes of the blockchain. For example, in Figure 1 In the blockchain node system shown, blockchain nodes 10a, 10b, 10c, and 10d can be used as consensus nodes within the blockchain node system. Consensus nodes within the blockchain node system participate in consensus, i.e., reaching consensus on blocks (containing a batch of transactions), including generating blocks and voting on blocks. Non-consensus nodes, on the other hand, do not participate in consensus, but help propagate block and voting information, and synchronize status with each other.

[0088] It is understandable that the above-mentioned data connection does not limit the connection method. It can be directly or indirectly connected through wired communication, directly or indirectly connected through wireless communication, or through other connection methods. This application does not limit this.

[0089] It is understood that the data processing method based on blockchain provided in the embodiments of the present application can be executed by a computer device, including but not limited to the above-mentioned blockchain node (which can be a terminal or a server). The above-mentioned server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The above-mentioned terminal can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, car terminal, etc., but is not limited to this.

[0090] It is understood that the embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc. For example, the blockchain node system can reach a consensus on some driving behavior data, road trajectory data, etc. sent by the vehicle terminal, and store it on the chain after the consensus is reached.

[0091] like Figure 1 As shown, the blockchain node in the blockchain node system (for example, blockchain node 10a) needs to access the blockchain ledger when performing transaction duplication check, contract query, block execution and other related processing. During the operation of blockchain node 10a, it may need to process thousands of transactions that need to be on-chain at the same time. The progress of these transactions on-chain is different. The functions provided by blockchain node 10a for different transactions are different. At the same time, there may be thousands of task requests that need to access the blockchain ledger. Among them, the task request may include query requests generated for the blockchain ledger. The task types of these task requests can be different, such as transaction execution type, transaction duplication check type, contract query type, etc. Among them, the task request of transaction execution type is a query request generated for the transaction contained in the block during the block execution process, which is used to obtain the transaction data corresponding to the transaction in order to execute the transaction; the task request of transaction duplication check type is a query request generated for the transaction during the transaction verification process, which is used to confirm whether the transaction is duplicated on the chain; the task request of contract query type is a query request generated for the contract, which is used to obtain the contract data associated with the contract. In order to avoid preemptive access to the blockchain ledger by tasks of different task types, thereby preventing all functions from operating smoothly, the blockchain node 10a can dynamically adjust the time for tasks of each task type to request access to the blockchain ledger, so that the functions corresponding to each task type can monopolize the storage resources corresponding to the blockchain ledger as much as possible, effectively reducing the resource waste caused by the preemptive storage resource occupation of each function and improving execution efficiency.

[0092] The specific process by which blockchain node 10a dynamically adjusts the access time of task requests of various task types to the blockchain ledger can be as follows: After receiving a target block, blockchain node 10a performs block verification, consensus, execution, and storage on the target block. When blockchain node 10a detects the start of execution of the target block, it suspends processing of the target access request queue for the blockchain ledger. The target access request queue contains queued task requests awaiting processing, none of which are of the transaction execution type. Blockchain node 10a then retrieves transaction execution task requests generated during the execution of the target block, accesses the blockchain ledger based on the task requests, obtains access results, and executes transactions in the target block based on the access results. Only after detecting the completion of execution of the target block does blockchain node 10a resume traversing the target access request queue and accessing the blockchain ledger based on the queued task requests in the target access request queue.

[0093] To better understand the above process, see Figure 2 , Figure 2 This is a schematic diagram of a scenario of data processing based on blockchain provided by an embodiment of the present application. The blockchain ledger in the blockchain node system is actually a decentralized distributed database. It is formed by connecting databases one by one to form a large distributed database. Each database has the same permissions and can view and store all data. Therefore, each blockchain node in the blockchain node system can correspond to a database, which can be called the blockchain ledger of the blockchain node. Each blockchain node is responsible for maintaining and managing its own blockchain ledger, and writing all consensus transactions and transaction-related data on the blockchain into the blockchain ledger. Figure 2 The blockchain node 20 shown can be the above Figure 1 Any blockchain node in the blockchain node system of the corresponding embodiment, such as blockchain node 10b, corresponds to a blockchain ledger 200. Blockchain node 20 can obtain all transactions and transaction-related data on the blockchain from blockchain ledger 200, because after executing a block, blockchain node 20 stores the block and the execution result in the ledger.

[0094] like Figure 2As shown, during operation, blockchain node 20 often needs to process multiple transactions simultaneously. Since these transactions are initiated at different times, blockchain node 20 processes different transactions at different speeds. Under different processing speeds, blockchain node 20 has different access requirements to the blockchain ledger, and the task types of the corresponding task requests are different. For example, when blockchain node 20 performs transaction verification on transaction A, it needs to determine whether transaction A exists in the blockchain ledger. Blockchain node 20 will generate task request a with a task type of transaction verification. Alternatively, when blockchain node 20 needs to obtain contract data for contract B, it can generate task request b with a task type of contract query. Alternatively, when blockchain node 20 processes transaction C during block execution, it will generate task request c with a task type of transaction execution, and so on. Since the blockchain node 20 processes multiple transactions in parallel, the execution of task requests also takes time. Therefore, at the same time, the blockchain node 20 may have multiple task requests waiting to be processed. The number of these task requests may exceed the number of task requests that the blockchain node 20 can process in parallel. Therefore, the blockchain node 20 can first treat all task requests that do not belong to the transaction execution type as queue task requests, add them to the access request queue 201, and then process the queue task requests in the access request queue 201 in sequence. Figure 2 As shown, the access request queue 201 includes queue task request 2011, queue task request 2012, queue task request 2013, queue task request 2014, ..., queue task request m. When the number of queue task requests in the access request queue 201 is too large, the blockchain node 20 cannot process them simultaneously, and will process some of the queue task requests in parallel. Assume that the blockchain node 20 is processing queue task request 2011 and queue task request 2012 in parallel at this time, and the remaining queue task requests are in a waiting state. After processing queue task request 2011 and queue task request 2012, the blockchain node 20 will sequentially process queue task request 2013 and queue task request 2014.

[0095] As can be seen from the above, the task type of the queue task request in the access request queue does not belong to the transaction execution type, because when the blockchain node 20 processes the execution task request of the task type belonging to the transaction execution type, it will suspend the processing of the access request queue 201. Figure 2As shown, each time blockchain node 20 receives a block to be uploaded, it monitors it as the target block. Assuming that blockchain node 20 receives target block 202, when blockchain node 20 monitors the start of execution of target block 202, it suspends processing of access request queue 201 for blockchain ledger 200. Optionally, when execution of target block 202 begins, queue task request 2011 and queue task request 2012 are already being processed in access request queue 201. Blockchain node 20 can first complete processing queue task request 2011 and queue task request 2012, and then stop processing the remaining queue task requests in access request queue 201. Suspending processing of access request queue 201 is to process transaction execution type execution task requests generated during the execution of target block 202. Specifically, target block 202 contains multiple transactions. Once the blockchain node system where blockchain node 20 is located reaches consensus on target block 202, blockchain node 20 will execute target block 202. Executing the target block 202 includes executing one or more transactions contained in the target block 202. When the blockchain node 20 executes a transaction in the target block 202, it may need to obtain transaction-related data before executing the transaction. At this time, an execution task request will be generated. When the blockchain node 20 processes the execution task request, it can obtain the data required for the transaction from the blockchain ledger 200. Figure 2 As shown, during the execution of target block 202, blockchain node 20 will obtain execution task requests belonging to the transaction execution type, namely execution task request 2021, execution task request 2022, ..., execution task request n. Blockchain node 20 will process these execution task requests in sequence according to the maximum number of concurrent processing. When blockchain node 20 processes the execution task request related to target block 202, blockchain node 20 will not process the queue task requests in access request queue 201. This can avoid frequent switching of access methods to the blockchain ledger by blockchain node 20 due to inconsistent task types, thereby causing conflicts and low operating efficiency. Figure 2 As shown, until the blockchain node 20 monitors that the execution of the target block 202 is completed, the blockchain node 20 will continue to traverse the access request queue 201. Assuming that the blockchain node 20 suspends processing the access request queue 201 after processing the queue task request 2011 and the queue task request 2012, the blockchain node 20 will start processing from the queue task request 2013.

[0096] Further, see Figure 3 , Figure 3 This is a flow chart of a data processing method based on blockchain provided by an embodiment of the present application. The data processing method can be performed by a blockchain node (for example, Figure 1 The data processing method is executed by any blockchain node in the blockchain node system in the corresponding embodiment. The following will be described as an example of the data processing method being executed by a blockchain node. Among them, the blockchain-based data processing method may at least include the following steps S101-S103:

[0097] Step S101: When the start of execution of the target block is detected, the processing of the access request queue for the blockchain ledger is suspended; the access request queue includes queue task requests; the task type of the queue task request does not belong to the transaction execution type.

[0098] Specifically, during the operation of a blockchain node, all steps in the transaction processing process, such as transaction execution, transaction verification, and ledger storage, require access to the blockchain ledger. Furthermore, blockchain nodes also need to access the blockchain ledger for user-initiated query requests. Requests for accessing the blockchain ledger can be referred to as task requests. Task requests generated during different processing processes have different task types, including transaction execution, transaction verification, contract query, and ledger storage. To better prevent preemptive access to the blockchain ledger by task requests of different types, blockchain nodes can dynamically adjust the access times for task requests of different types.

[0099] Specifically, transaction execution-type execution task requests are generated by blockchain nodes for transactions within a block when they execute a block. Since a block often contains multiple transactions, multiple transaction execution-type execution task requests are generated within a short period of time. Therefore, during block execution, blockchain nodes can temporarily suspend processing of other task requests and only process execution task requests. In large-scale blockchain node systems, blockchain nodes may receive a large number of task requests, far exceeding the number of task requests they can concurrently execute. Therefore, blockchain nodes can treat all task requests that are not transaction execution-type as queued task requests and add them to the access request queue. When the blockchain node is not executing a block, the node processes the access request queue sequentially. In short, when a blockchain node is not executing a block, it processes queued task requests in the access request queue, accessing the blockchain ledger based on these queued task requests. When executing a block, it suspends queued task requests in the access request queue and only processes execution task requests.

[0100] Specifically, whenever a blockchain node receives a new proposed block, or when it itself packages a new proposed block as a block producer, it monitors it as a target block. When it detects the start of execution of the target block, the node pauses processing access requests to the blockchain ledger. This monitoring of the target block can be implemented by a flow control unit, which can be a process component or application software.

[0101] Optionally, upon detecting the start of execution of the target block, the blockchain node can search the access request queue for the blockchain ledger for the currently processing queue task request and identify the currently processing queue task request as the target queue task request. When the target queue task request is processed, the access request queue is paused. In short, queue task requests that have already been processed in the access request queue can continue to be processed, while queue task requests that have not yet been processed are stopped.

[0102] Step S102: Obtain an execution task request of a transaction execution type, access the blockchain ledger according to the execution task request, obtain an execution access result, and execute the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block.

[0103] Specifically, the target block often contains multiple transactions. When a blockchain node executes the target block, it actually executes multiple transactions within it. Some transactions require obtaining historical transaction data before they can be executed. This requires accessing the blockchain ledger to obtain this historical transaction data. For example, let's assume that Transaction 1 involves Party A transferring 10 yuan from their own account to Party B. The balance in Party A's account before the transfer is the historical transaction data. During the execution of Transaction 1, Execution Task Request 1 is generated to read Party A's account balance. Upon receiving Execution Task Request 1, the blockchain node accesses the blockchain ledger based on Execution Task Request 1 to read Party A's account balance. Assuming the balance is 20, the blockchain node returns 20 as the Execution Access Result. Based on this Execution Access Result, blockchain node 20 can proceed with Transaction 1. The Transaction Execution Result 1 for Transaction 1 could be 20 - 10 = 10 yuan. This means that after executing Transaction 1, Party A's account balance will be 10 yuan.

[0104] Step S103: When it is monitored that the execution of the target block is completed, continue to traverse the access request queue and request access to the blockchain account book according to the queue task in the access request queue.

[0105] Specifically, if no new task requests that do not belong to the transaction execution type are generated during the execution of the target block, the access request queue will not be updated. When the target block execution is monitored to be completed and the access request queue has not been updated, the access request queue will continue to be traversed, and the blockchain ledger will be accessed according to the queued task requests in the access request queue.

[0106] Optionally, during the execution of the target block, if a new task request that does not fall under the transaction execution type is received, the new task request is added to the end of the access request queue, resulting in an updated access request queue. Suppose the access request queue sequentially contains queue task request 1, queue task request 2, ..., queue task request n. At this time, the target block is being executed, but the blockchain node receives a new task request k that does not fall under the transaction execution type. The blockchain node will treat the new task request k as queue task request n+1 and then add queue task request n+1 to the access request queue, resulting in an updated access request queue. The updated access request queue also contains queue task request 1, queue task request 2, ..., queue task request n, and queue task request n+1. Subsequently, when the blockchain node detects that the target block execution has completed and the access request queue has been updated, it traverses the updated access request queue and accesses the blockchain ledger based on the queue task requests and new task requests in the updated access request queue. It can be understood that the updated access request queue is obtained based on the updated access request queue and includes queue task requests and new task requests that do not fall under the transaction execution type.

[0107] By using the method provided in the embodiment of the present application, when the execution of the target block is monitored, the processing of the access request queue for the blockchain ledger can be suspended, and then an execution task request of the transaction execution type can be obtained. The blockchain ledger can be accessed according to the execution task request to obtain the execution access result. The transaction in the target block can be executed according to the execution access result. When the execution of the target block is monitored, the access request queue can be continued to be traversed, and the blockchain ledger can be accessed according to the queue task request in the access request queue. By distributing the task requests of different task types into different time periods for processing, that is, during the execution of the target block, only the execution task requests of the transaction execution type generated during the execution process are processed, and other queue task requests that are not of the transaction execution type are suspended. In the time period between the completion of the target block execution and the start of the new target block execution, other queue task requests that are not of the transaction execution type can be continued to be processed. This can improve the situation where multiple functions access the blockchain ledger in parallel, effectively reduce the preemption of storage resources by each function, and improve the performance of the blockchain.

[0108] The transaction processing process in the blockchain mentioned above mainly includes the steps of transaction propagation, transaction pool verification, transaction packaging into blocks, block consensus, transaction execution and storage in the ledger. For ease of understanding, please refer to Figure 4a , Figure 4a This is a blockchain transaction processing sequence diagram provided by the embodiment of this application. Figure 4a As shown, a terminal device can generate a transaction (also called transaction data) through a decentralized application. The terminal device then sends the transaction to a blockchain node in the blockchain network, such as blockchain node A. Blockchain node A then broadcasts the transaction to the remaining blockchain nodes in the blockchain network, namely blockchain nodes B and C. Each blockchain node in the blockchain network is required to verify the received transaction. If the transaction fails, it is ignored; if the transaction succeeds, it is stored in the transaction pool. Subsequently, a block-producing node (which can be any node in the blockchain network, selected through a polling mechanism or other mechanisms) needs to obtain one or more transactions from the transaction pool and then generate a proposed block based on these transactions. Assuming that blockchain node C is the block-producing node, after generating a proposed block, blockchain node C broadcasts the proposed block to the other blockchain nodes. Each blockchain node then performs block verification on the proposed block and obtains a block verification result. If the block verification result is a pass, the blockchain node's block processing node generates a consensus pass vote for the proposed block. If the block verification result is a fail, the blockchain node's block processing node generates a consensus fail vote for the proposed block. The voting results of each blockchain node are then broadcast to the other blockchain nodes. When the number of blockchain nodes that generate consensus pass votes for the proposed block exceeds the consensus threshold, the proposed block is considered to have passed consensus. Finally, after confirming that the proposed block has passed consensus, each blockchain node executes one or more transactions within the proposed block, obtains the transaction execution results, and then writes the proposed block and transaction execution results to the blockchain ledger.

[0109] Specifically, in the above Figure 4a During the blockchain transaction processing, both transaction execution and transaction weight verification will access the blockchain ledger. Transaction weight verification is a method of transaction verification to confirm whether the transaction has been stored in the blockchain ledger. In addition to the above process, querying the blockchain ledger also includes contract querying. For easier understanding, please refer to Figure 4b , Figure 4b This is a blockchain query processing sequence diagram provided by the embodiment of this application. Figure 4bAs shown, the terminal device generates a query request through a decentralized application. The blockchain node responds to the query request and calls the query contract in the smart contract. Then, according to the instructions of the query contract, it accesses the blockchain ledger to query the required data. The blockchain ledger then returns the required data. The blockchain node obtains the contract execution result of the query contract based on the data returned by the blockchain ledger. The blockchain node then returns the contract execution result to the decentralized application. Among them, the query request includes transaction query, contract query, block query, etc. It can be understood that the above Figure 4a In the process of storing data in the ledger, the blockchain node also needs to access the blockchain ledger, but it is more of a write operation on the blockchain ledger, that is, writing new data into the blockchain ledger.

[0110] As mentioned above, the flow control unit can be used to dynamically adjust the time for task requests of each transaction execution type to access the blockchain ledger. Please refer to Figure 4c , Figure 4c This is a schematic diagram of a blockchain ledger call provided by the embodiment of this application. Figure 4c As shown, when a blockchain node performs operations such as transaction verification, transaction execution, contract query, and storage of block or contract data, it can first search the cache for relevant data. If the data is not in the cache, it must search the blockchain ledger. Task requests corresponding to each operation will reach the flow control unit, which then determines which task request to process first. The flow control unit can run and process task requests based on the different operations corresponding to the task requests, that is, different task types. For example, after consensus on the target block is reached and the blockchain node begins executing the target block, the flow control unit will process task requests corresponding to transaction execution. During times other than the target block execution, when the blockchain node confirms the legitimacy of a newly received transaction, the flow control unit can process task requests corresponding to transaction verification for the legitimate new transaction. During times other than the target block execution, the flow control unit can respond to contract query requests.

[0111] In short, transaction execution has the highest priority. When a transaction is executed, other ledger access functions are suspended. After the current block is processed, it is necessary to wait for the arrival of the next block. During this time, other ledger data access functions can be performed, such as contract query, transaction duplication check, and data saving. For easier understanding, please refer to Figure 4d , Figure 4d This is a schematic diagram of access time distribution provided by the embodiment of this application. Figure 4d As shown in the figure, through the flow control unit, the access traffic of the blockchain node to the ledger data can be dispersed into different time slices, so that the blockchain node can obtain as much storage resources as possible when performing various operations, and the processing speed will be faster, thereby improving the overall performance of the blockchain.

[0112] Further, see Figure 5 , Figure 5 This is a flow chart of a data processing method based on blockchain provided by an embodiment of the present application. The data processing method can be performed by a blockchain node (for example, Figure 1 The data processing method is executed by any blockchain node in the blockchain node system in the corresponding embodiment. The following will be described as an example of the data processing method being executed by a blockchain node. Among them, the blockchain-based data processing method may at least include the following steps S201-S203:

[0113] Step S201: When the execution of the target block is detected to have started, the processing of the access request queue for the blockchain ledger is suspended; the access request queue includes queue task requests; and the task type of the queue task request does not belong to the transaction execution type.

[0114] Step S202: Obtain an execution task request of a transaction execution type, access the blockchain ledger according to the execution task request, obtain an execution access result, and execute the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block.

[0115] Specifically, the implementation process of step S201 and step S202 can refer to the detailed description of step S102-step S102 above, which will not be repeated here.

[0116] Step S203: When the execution of the target block is monitored to be completed, continue to traverse the access request queue and access the blockchain ledger according to the queue task requests in the access request queue; the number of queue task requests is M; M is a positive integer.

[0117] Specifically, when processing the M queue task requests in the access request queue, the blockchain node may also prioritize which queue task requests to process based on a comprehensive consideration of the task type, priority, and waiting time of the M queue task requests.

[0118] In a feasible embodiment, the number of task types of the M queue task requests is at least two. When the execution of the target block is monitored to be completed, the access request queue is continued to be traversed. The specific implementation process of accessing the blockchain ledger according to the queue task requests in the access request queue can be: when the execution of the target block is monitored to be completed, the access request queue is continued to be traversed, and the M queue task requests are sorted and processed according to the priorities of at least two task types; the sorted M queue task requests are processed in sequence, the blockchain ledger is accessed according to the processed queue task requests, and the request access result is obtained, and the task indicated by the processed queue task request is processed according to the request access result. For example, a blockchain node can process up to two queue task requests concurrently, and the access request queue contains four queue task requests, namely, queue task request 1, queue task request 2, queue task request 3, and queue task request 4. Among them, the task type of queue task request 1 and queue task request 4 is the contract query type, and the task type of queue task request 2 and queue task request 3 is the transaction weight verification type. Assuming that the priority of the contract query type is higher than the transaction weight verification type, the blockchain node will sort and process these four queue task requests. The resulting four sorted queue task requests are queue task request 1, queue task request 4, queue task request 2, and queue task request 3. The blockchain node will first process queue task request 1 and queue task request 4, and then process queue task request 2 and queue task request 3.

[0119] In a feasible embodiment, the task types of the M queue task requests include a first task type and a second task type. When the execution of the target block is monitored to be completed, the access request queue is continued to be traversed. The specific implementation process of accessing the blockchain ledger according to the queue task requests in the access request queue can be: when the execution of the target block is monitored to be completed, the access request queue is continued to be traversed, and k queue task requests belonging to the first task type are sequentially obtained from the M queue task requests as k first queue task requests; k is a positive integer less than M; s queue task requests belonging to the second task type are sequentially obtained from the M queue task requests as s second queue task requests; s is a positive integer less than M; according to the priorities corresponding to the first task type and the second task type, the k first queue task requests and the s second queue task requests are sorted to obtain a pending task queue, and the blockchain ledger is accessed according to the first queue task requests and the second queue task requests in the pending task queue. The queue task requests in the access request queue are sorted in chronological order, but the task types of different queue task requests are different. The task types of the same task request in the access request queue may be relatively scattered. For example, the access request queue contains queue task request 1 belonging to the first task type, queue task request 2 belonging to the second task type, queue task request 3 belonging to the first task type, queue task request 4 belonging to the second task type, queue task request 5 belonging to the first task type, ..., queue task request m belonging to the second task type. It can be seen that after the blockchain node processes the queue task request of the first task type, it immediately processes the queue task request of the second task type, and so on. Switching, the processing efficiency is not high. Therefore, the blockchain node can first obtain two queue task requests belonging to the first task type in sequence, namely queue task request 1 and queue task request 3, as the first queue task request, and then obtain two queue task requests belonging to the second task type in sequence, namely queue task request 2 and queue task request 4, as the second queue task request. Assuming that the priority of the second task type is higher than that of the first task type, the blockchain node will sort the first queue task request and the second queue task request to obtain the pending task queue: queue task request 2, queue task request 4, queue task request 1 and queue task request 3. Then, the blockchain node processes the pending task queue in sequence.

[0120] In a feasible embodiment, when the execution of the target block is monitored to be completed, the access request queue is continued to be traversed, and the specific implementation process of accessing the blockchain ledger according to the queue task request in the access request queue can be: when the execution of the target block is monitored to be completed, the access request queue is continued to be traversed to obtain the waiting processing time corresponding to each queue task request in the M queue task requests; according to the waiting time range to which the waiting processing time belongs, the priority corresponding to each queue task request is determined, and different priorities are mapped to different waiting time ranges; the M queue task requests are sorted according to the priority corresponding to each queue task request; the sorted M queue task requests are processed in sequence, and the blockchain ledger is accessed according to the processed queue task requests. For example, the access request queue includes queue task request 1, queue task request 2, queue task request 3, queue task request 4 and queue task request 5. The waiting time for queue task request 1 is 18 seconds, the waiting time for queue task request 2 is 65 seconds, the waiting time for queue task request 3 is 75 seconds, the waiting time for queue task request 4 is 5 seconds, and the waiting time for queue task request 5 is 45 seconds. Assuming that the waiting time for processing is within 30 seconds, it corresponds to the first priority, the waiting time for processing is within 30 seconds to 60 seconds, it corresponds to the second priority, and the waiting time for processing exceeds 60 seconds, it corresponds to the third priority. The longer the waiting time, the higher the priority level. After reordering the M queue task requests, we get: queue task request 2, queue task request 3, queue task request 5, queue task request 1 and queue task request 4.

[0121] Optionally, when the task indicated by the queue task request being processed is completed, the queue task request in the processing completed state is deleted from the access request queue.

[0122] By using the method provided in the embodiment of the present application, queue task requests of different task types processed by blockchain nodes are sorted so that tasks with higher priorities can be processed first, and queue task requests of the same task type can be processed together, thereby improving the operating efficiency of blockchain nodes.

[0123] Further, see Figure 6 , Figure 6 This is a flow chart of a data processing method based on blockchain provided by an embodiment of the present application. The data processing method can be performed by a blockchain node (for example, Figure 1 The data processing method is executed by any blockchain node in the blockchain node system in the corresponding embodiment. The following will be described as an example of the data processing method being executed by a blockchain node. Among them, the blockchain-based data processing method may at least include the following steps S301-S303:

[0124] Step S301: When the start of target block execution is detected, the processing of the access request queue for the blockchain ledger is suspended; the access request queue includes queue task requests; the task type of the queue task request does not belong to the transaction execution type.

[0125] Step S302: Obtain an execution task request of a transaction execution type, access the blockchain ledger according to the execution task request, obtain an execution access result, and execute the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block.

[0126] Specifically, the implementation process of step S301 and step S302 can refer to the detailed description of step S102-step S102 above, which will not be repeated here.

[0127] Step S303: When the execution of the target block is monitored to be completed, the access request queue is continued to be traversed, the target queue task request is obtained from the access request queue, and the blockchain ledger is accessed according to the task type of the target queue task request.

[0128] Specifically, if the target queue task request type is a transaction duplication type, the target transaction is read from the target task request and the blockchain ledger is queried based on the target transaction. If the blockchain ledger contains the same transaction data as the target transaction, the access result corresponding to the target queue task request is determined to be a duplicate transaction result. If the blockchain ledger does not contain the same transaction data as the target transaction, the access result corresponding to the target queue task request is determined to be a non-duplicate transaction result. The purpose of transaction duplication verification is to prevent duplicate transactions from being uploaded to the blockchain.

[0129] Specifically, if the task type of the target queue task request is a contract query type, the target contract information is read from the target queue task request, the contract data associated with the target contract information is searched in the blockchain account book, and the contract data is used as the access result corresponding to the target task request. For details, please refer to the above Figure 4b The description in the corresponding embodiment will not be repeated here.

[0130] Specifically, if the task type of the target queue task request is the type of storage in the ledger, the data to be uploaded to the chain is obtained according to the target queue task request, and the data to be uploaded to the chain is stored in the blockchain ledger.

[0131] See Figure 7, is a structural diagram of a data processing device based on blockchain provided in an embodiment of the present application. The data processing device can be a computer program (including program code) running on a computer device, for example, the data processing device is an application software; the device can be used to execute the corresponding steps in the data processing method provided in an embodiment of the present application. Figure 7 As shown, the data processing device 1 may include: a first monitoring module 11 , an access module 12 and a second monitoring module 13 .

[0132] The first monitoring module 11 is configured to suspend processing of an access request queue for the blockchain ledger upon monitoring the start of execution of a target block; the access request queue includes queue task requests; the task type of the queue task request does not belong to the transaction execution type;

[0133] Access module 12, configured to obtain an execution task request of a transaction execution type, access the blockchain ledger according to the execution task request, obtain an execution access result, and execute the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block;

[0134] The second monitoring module 13 is used to continue traversing the access request queue when it monitors that the execution of the target block has ended, and access the blockchain ledger according to the queue task request in the access request queue.

[0135] The specific implementation of the first monitoring module 11, the access module 12 and the second monitoring module 13 can be found in the above Figure 3 The description of steps S101 to S103 in the corresponding embodiment will not be repeated here.

[0136] See Figure 7 The first monitoring module 11 may include: a processing request determining unit 1101 and a pausing unit 1102 .

[0137] The processing request determination unit 1101 is configured to, when monitoring the start of execution of the target block, search for a queue task request being processed in the access request queue for the blockchain ledger, and determine the queue task request being processed as the target queue task request;

[0138] The pausing unit 1102 is configured to suspend processing of the access request queue when the processing of the target queue task request is completed.

[0139] The specific implementation of the processing request determination unit 1101 and the suspension unit 1102 can be found in the above Figure 3 The description of step S101 in the corresponding embodiment will not be repeated here.

[0140] See Figure 7The second monitoring module 13 may include: a monitoring access unit 1301 and a first account book access unit 1302.

[0141] The monitoring access unit 1301 is configured to continue traversing the access request queue when it is monitored that the execution of the target block is completed and the access request queue has not been updated;

[0142] A first ledger access unit 1302 is configured to access the blockchain ledger according to a queue task request in the access request queue;

[0143] The specific implementation of the monitoring access unit 1301 and the first account book access unit 1302 can be found in the above Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0144] See Figure 7 The above-mentioned data processing device 1 also includes: a third monitoring module 14.

[0145] The third monitoring module 14 is configured to traverse and update the access request queue upon monitoring the completion of execution of the target block and the update of the access request queue; the updated access request queue is obtained based on the update of the access request queue, and the updated access request queue includes queue task requests and new task requests that do not belong to the transaction execution type;

[0146] The third monitoring module 14 is further configured to access the blockchain ledger according to the queue task request and the new task request in the update access request queue.

[0147] The specific implementation of the third monitoring module 14 can be found in the above Figure 3 The description of the optional embodiment of step S103 in the corresponding embodiment will not be repeated here.

[0148] See Figure 7 The above-mentioned data processing device 1 also includes: a queue updating module 15.

[0149] The queue updating module 15 is configured to add a new task request that does not belong to a transaction execution type to the tail of the access request queue during the execution process for the target block, thereby obtaining an updated access request queue.

[0150] The specific implementation of the queue update module 15 can be found in the above Figure 3 The description of the optional embodiment of step S103 in the corresponding embodiment will not be repeated here.

[0151] The number of queue task requests is M; the number of task types of the M queue task requests is at least two; M is a positive integer;

[0152] See Figure 7 The second monitoring module 13 may include: a sorting unit 1303 and a second account book accessing unit 1304.

[0153] The sorting unit 1303 is configured to, upon monitoring the completion of execution of the target block, continue to traverse the access request queue and sort the M queue task requests according to the priorities of at least two task types;

[0154] The second ledger access unit 1304 is configured to sequentially process the sorted M queue task requests, access the blockchain ledger according to the processed queue task requests, obtain a request access result, and process the task indicated by the processed queue task request according to the request access result.

[0155] The specific implementation of the sorting unit 1303 and the second ledger access unit 1304 can be found in the above Figure 5 The description of step S203 in the corresponding embodiment will not be repeated here.

[0156] The data processing device 1 further includes a deletion module 16 .

[0157] The deleting module 16 is configured to delete the queue task request in a processing completed state from the access request queue when the task indicated by the queue task request being processed is completed.

[0158] The specific implementation of the deletion module 16 can be found in the above Figure 5 The optional description of step S203 in the corresponding embodiment will not be repeated here.

[0159] The number of queue task requests is M; the task types of the M queue task requests include a first task type and a second task type; M is a positive integer;

[0160] See Figure 7 The second monitoring module 13 may include: a first request obtaining unit 1305 , a second request obtaining unit 1306 and a third account book accessing unit 1307 .

[0161] The first request acquisition unit 1305 is configured to, upon monitoring the completion of execution of the target block, continue to traverse the access request queue and sequentially acquire k queue task requests of the first task type from the M queue task requests as k first queue task requests, where k is a positive integer less than M.

[0162] The second request obtaining unit 1306 is configured to obtain, in sequence, s queue task requests belonging to the second task type from the M queue task requests as s second queue task requests; s is a positive integer less than M;

[0163] The third ledger access unit 1307 is configured to sort the k first-queue task requests and the s second-queue task requests according to the priorities corresponding to the first task type and the second task type, respectively, to obtain a pending task queue, and access the blockchain ledger according to the first-queue task requests and the second-queue task requests in the pending task queue.

[0164] The specific implementation of the first request acquisition unit 1305, the second request acquisition unit 1306 and the third account access unit 1307 can be found in the above Figure 5 The description of step S203 in the corresponding embodiment will not be repeated here.

[0165] Among them, the number of queue task requests is M; M is a positive integer;

[0166] See Figure 7 The second monitoring module 13 may include: a waiting time determination unit 1308 , a priority determination unit 1309 and a fourth account book access unit 1310 .

[0167] The waiting time determination unit 1308 is configured to, upon monitoring the completion of execution of the target block, continue to traverse the access request queue to obtain the waiting processing time corresponding to each of the M queue task requests;

[0168] The priority determination unit 1309 is configured to sort the M queue task requests according to the priority corresponding to each queue task request;

[0169] The fourth ledger access unit 1310 is configured to process the sorted M queue task requests in sequence and access the blockchain ledger according to the processed queue task requests.

[0170] The specific implementation of the waiting time determination unit 1308, the priority determination unit 1309 and the fourth account book access unit 1310 can be found in the above Figure 5 The description of step S203 in the corresponding embodiment will not be repeated here.

[0171] See Figure 7 The second monitoring module 13 may include: a third request obtaining unit 1311 and a fifth account book accessing unit 1312.

[0172] The third request acquisition unit 1311 is configured to, upon monitoring the completion of execution of the target block, continue to traverse the access request queue and acquire the target queue task request from the access request queue;

[0173] The fifth ledger access unit 1312 is configured to read the target transaction from the target task request if the task type of the target queue task request is a transaction weight verification type, and query the blockchain ledger based on the target transaction;

[0174] The fifth ledger access unit 1312 is further configured to determine that the access result corresponding to the target queue task request is a duplicate transaction result if transaction data identical to the target transaction is found in the blockchain ledger;

[0175] The fifth ledger access unit 1312 is further configured to determine that the access result corresponding to the target queue task request is a non-duplicate transaction result if no transaction data identical to the target transaction is found in the blockchain ledger.

[0176] The specific implementation of the third request acquisition unit 1311 and the fifth account book access unit 1312 can be found in the above Figure 6 The description of step S303 in the corresponding embodiment will not be repeated here.

[0177] See Figure 7 The second monitoring module 13 may include: a fourth request obtaining unit 1313 and a sixth account book accessing unit 1314.

[0178] The fourth request obtaining unit 1313 is configured to, upon monitoring that the execution of the target block has ended, continue to traverse the access request queue and obtain the target queue task request from the access request queue;

[0179] The sixth ledger access unit 1314 is configured to read target contract information from the target queue task request if the task type of the target queue task request is a contract query type, query the blockchain ledger for contract data associated with the target contract information, and use the contract data as the access result corresponding to the target task request.

[0180] The specific implementation of the fourth request acquisition unit 1313 and the sixth account book access unit 1314 can be found in the above Figure 6 The description of step S303 in the corresponding embodiment will not be repeated here.

[0181] See Figure 7 The second monitoring module 13 may include: a fifth request obtaining unit 1315 and a seventh account book accessing unit 1316.

[0182] The fifth request obtaining unit 1315 is configured to, upon monitoring that the execution of the target block has ended, continue to traverse the access request queue and obtain the target queue task request from the access request queue;

[0183] The seventh ledger access unit 1316 is configured to obtain the data to be uploaded to the blockchain according to the target queue task request if the task type of the target queue task request is a type of storing in the blockchain, and store the data to be uploaded to the blockchain in the blockchain ledger.

[0184] The specific implementation of the fifth request acquisition unit 1315 and the seventh account book access unit 1316 can be found in the above Figure 6 The description of step S303 in the corresponding embodiment will not be repeated here.

[0185] See Figure 8 , is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 8 As shown, the computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the above-mentioned computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the user interface 1003 may optionally include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may optionally also be at least one storage device located away from the aforementioned processor 1001. As Figure 8 As shown, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application.

[0186] In such Figure 8 In the computer device 1000 shown, the network interface 1004 can provide a network communication element; the user interface 1003 is mainly used to provide an interface for user input; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0187] When the execution of the target block is detected, the processing of the access request queue for the blockchain ledger is suspended; the access request queue includes queue task requests; the task type of the queue task request does not belong to the transaction execution type;

[0188] Obtaining an execution task request of the transaction execution type, accessing the blockchain ledger according to the execution task request, obtaining the execution access result, and executing the transaction in the target block according to the execution access result; the execution task request is generated during the execution process of the target block;

[0189] When the target block execution is detected, continue to traverse the access request queue and request access to the blockchain ledger according to the queue task in the access request queue.

[0190] It should be understood that the computer device 1000 described in the embodiment of the present application can execute the above Figure 3 、 Figure 5 、 Figure 6 The description of the blockchain-based data processing method in any corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

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

[0192] The computer-readable storage medium can be the blockchain-based data processing device provided in any of the aforementioned embodiments, or the internal storage unit of the computer device, such as the computer device's hard drive or memory. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, the computer-readable storage medium can include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or is about to be output.

[0193] In addition, it should be noted that the present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the above-mentioned Figure 3 、 Figure 5 、 Figure 6 The method provided by any corresponding embodiment.

[0194] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0195] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example in terms of network elements. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel may use different methods to implement the described network elements for each specific application, but such implementation should not be considered to be beyond the scope of this application.

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

Claims

1. A data processing method based on blockchain, characterized in that: include: When the execution of the target block is detected, the processing of the access request queue for the blockchain ledger is suspended; The access request queue includes queue task requests; The task type of the queue task request does not belong to the transaction execution type; Obtaining an execution task request of a transaction execution type, accessing the blockchain ledger according to the execution task request, obtaining an execution access result, and executing the transaction in the target block according to the execution access result; the execution task request is generated during the execution process for the target block; When the execution of the target block is monitored to be completed, the access request queue is continued to be traversed, and the blockchain account book is accessed according to the queue task request in the access request queue.

2. The method according to claim 1, characterized in that When the execution of the target block is detected to have started, the access request queue for the blockchain account book is suspended, including: When the execution of the target block is detected to have started, the queue task request being processed is searched in the access request queue for the blockchain ledger, and the queue task request being processed is determined as the target queue task request; When the processing of the target queue task request is completed, the processing of the access request queue is suspended.

3. The method according to claim 1, characterized in that When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When it is monitored that the execution of the target block is completed and the access request queue has not been updated, continue to traverse the access request queue and request access to the blockchain ledger according to the queue task in the access request queue; The method further comprises: When monitoring the completion of the execution of the target block and the access request queue is updated, traversing and updating the access request queue; the updated access request queue is obtained based on the update of the access request queue, and the updated access request queue includes the queue task requests and new task requests that do not belong to the transaction execution type; Access the blockchain ledger according to the queue task request and the new task request in the update access request queue.

4. The method according to claim 3, characterized in that Also includes: During the execution process for the target block, if a new task request that does not belong to the transaction execution type is received, the new task request is added to the end of the access request queue to obtain an updated access request queue.

5. The method according to claim 1, wherein The number of queue task requests is M; the number of task types of the M queue task requests is at least two; M is a positive integer; When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and the M queue task requests are sorted according to the priorities of at least two task types; The sorted M queue task requests are processed in sequence, the blockchain ledger is accessed according to the processed queue task requests, a request access result is obtained, and the task indicated by the processed queue task request is processed according to the request access result.

6. The method according to claim 5, characterized in that Also includes: When the task indicated by the queue task request being processed is completed, the queue task request in the processing completion state is deleted from the access request queue.

7. The method according to claim 1, characterized in that The number of queue task requests is M; the task types of the M queue task requests include a first task type and a second task type; M is a positive integer; When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and k queue task requests belonging to the first task type are sequentially obtained from the M queue task requests as k first queue task requests; k is a positive integer less than M; Sequentially obtain s queue task requests belonging to the second task type from the M queue task requests as s second queue task requests; s is a positive integer less than M; The k first-queue task requests and the s second-queue task requests are sorted according to the priorities corresponding to the first task type and the second task type, respectively, to obtain a pending task queue, and the blockchain ledger is accessed according to the first-queue task requests and the second-queue task requests in the pending task queue.

8. The method according to claim 1, characterized in that The number of queue task requests is M; M is a positive integer; When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed to obtain the waiting processing time corresponding to each queue task request in the M queue task requests; Determine the priority level corresponding to each queue task request according to the waiting time range to which the waiting processing time belongs, and map different priorities to different waiting time ranges; Sorting the M queue task requests according to the priority corresponding to each queue task request; The sorted M queue task requests are processed in sequence, and the blockchain ledger is accessed according to the processed queue task requests.

9. The method according to claim 1, characterized in that When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When monitoring that the execution of the target block is completed, continue to traverse the access request queue and obtain the target queue task request from the access request queue; If the task type of the target queue task request is a transaction weight verification type, then read the target transaction from the target task request, and query the blockchain ledger according to the target transaction; If transaction data identical to the target transaction is found in the blockchain ledger, determining that the access result corresponding to the target queue task request is a duplicate transaction result; If transaction data identical to the target transaction is not found in the blockchain account book, it is determined that the access result corresponding to the target queue task request is a non-duplicate transaction result.

10. The method according to claim 1, characterized in that When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When monitoring that the execution of the target block is completed, continue to traverse the access request queue and obtain the target queue task request from the access request queue; If the task type of the target queue task request is a contract query type, the target contract information is read from the target queue task request, the contract data associated with the target contract information is queried in the blockchain account book, and the contract data is used as the access result corresponding to the target task request.

11. The method according to claim 1, wherein When the execution of the target block is monitored to be finished, the access request queue is continued to be traversed, and access to the blockchain ledger is requested according to the queue task in the access request queue, including: When monitoring that the execution of the target block is completed, continue to traverse the access request queue and obtain the target queue task request from the access request queue; If the task type of the target queue task request is a type of storing in an account book, the data to be uploaded to the chain is obtained according to the target queue task request, and the data to be uploaded to the chain is stored in the blockchain account book.

12. A data processing device based on blockchain, characterized in that: include: A first monitoring module is configured to suspend processing of an access request queue for the blockchain ledger when detecting that execution of a target block has started; The access request queue includes a queue task request; the task type of the queue task request does not belong to the transaction execution type; an access module, configured to obtain an execution task request of a transaction execution type, access the blockchain ledger according to the execution task request, obtain an execution access result, and execute the transaction in the target block according to the execution access result; the execution task request is generated during the execution process for the target block; The second monitoring module is used to continue traversing the access request queue when monitoring the completion of the execution of the target block, and access the blockchain ledger according to the queue task request in the access request queue.

13. A computer device, characterized in that: include: processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide a data communication function, the memory is used to store program code, and the processor is used to call the program code to execute the method described in any one of claims 1-11.

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

15. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 1 to 11 can be performed.

Images