CN116016374A

CN116016374A - Block chain-based data processing method, device, equipment and readable storage medium

Info

Publication number: CN116016374A
Application number: CN202111217563.2A
Authority: CN
Inventors: 刘区城
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-10-19
Filing date: 2021-10-19
Publication date: 2023-04-25

Abstract

The invention discloses a data processing method, a device, equipment and a readable storage medium based on a blockchain, wherein the method comprises the following steps: when the execution start of the target block is monitored, suspending processing of an access request queue aiming at the block chain ledger; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type; acquiring an execution task request belonging to a transaction execution type, accessing a block chain account book according to the execution task request, obtaining an execution access result, and executing a transaction in a target block according to the execution access result; the execution task request is generated during execution for the target block; and when the target block execution is monitored to be finished, continuing to traverse the access request queue, and requesting to access the block chain ledger according to the queue task in the access request queue. By adopting the invention, the preemption of storage resources by each function can be reduced, and the performance of the block chain is improved.

Description

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

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a data processing method, apparatus, device and readable storage medium based on a blockchain.

Background

The block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like, and is mainly used for sorting data according to time sequence, encrypting the data into an account book, preventing the account book from being tampered and forged, and simultaneously verifying, storing and updating the data. The blockchain can also carry out data encryption transmission, node identification and secure access, and is an advanced distributed infrastructure. Currently, there are also increasing applications for blockchains because of their non-tamperability and authenticity.

Currently, in blockchain networks built by some popular blockchain protocols, all functions required for transaction uplink are usually completed by core nodes, i.e. full nodes, such as: transaction broadcasting, transaction verification, block packing, block consensus, transaction execution, contract inquiry, ledger deposit, and the like. When the functions of transaction verification, transaction execution, contract inquiry and the like are realized, the blockchain ledger needs to be accessed. In some large blockchain projects, such as tax blockchains, because of wide audience and centralized business handling time, the blockchain network needs to perform thousands of transactions for uplink in the same time period, and the functions currently required by different transactions are different, and a large number of functions currently required by the transactions are parallel, the partial functions of transaction verification, transaction execution, contract inquiry and the like can preemptively access the blockchain ledger, and the operation efficiency of the core node can be reduced due to a large amount of conflicts or context switching generated by preempting the blockchain ledger, so that each function cannot operate efficiently and smoothly.

Disclosure of Invention

The embodiment of the application provides a data processing method, device and equipment based on a blockchain and a readable storage medium, which can effectively reduce the preemption of storage resources by each function and improve the blockchain performance.

An aspect of an embodiment of the present application provides a data processing method based on a blockchain, including:

when the execution start of the target block is monitored, suspending processing of an access request queue aiming at the block chain ledger; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type;

acquiring an execution task request belonging to a transaction execution type, accessing a block chain account book according to the execution task request, obtaining an execution access result, and executing a transaction in a target block according to the execution access result; the execution task request is generated during execution for the target block;

and when the target block execution is monitored to be finished, continuing to traverse the access request queue, and requesting to access the block chain ledger according to the queue task in the access request queue.

An aspect of an embodiment of the present application provides a data processing apparatus based on a blockchain, including:

the first monitoring module is used for suspending processing of an access request queue aiming at the blockchain ledger when monitoring that the execution of the target block starts; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type;

The access module is used for acquiring an execution task request belonging to 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 execution for the target block;

and the second monitoring module is used for continuously traversing the access request queue when the target block execution is monitored to be finished, and requesting to access the block chain ledger according to the queue task in the access request queue.

Wherein, the first monitoring module includes:

the processing request determining unit is used for searching a queue task request being processed in an access request queue aiming at the blockchain ledger when monitoring that the target block starts to execute, and determining the queue task request being processed as the target queue task request;

and the suspension unit is used for suspending processing of the access request queue when the target queue task request processing is completed.

Wherein, the second monitoring module includes:

the monitoring access unit is used for continuing to traverse the access request queue when the target block is monitored to finish execution and the access request queue is not updated;

The first account access unit is used for requesting to access the blockchain account according to the queue task in the access request queue;

the above data processing apparatus further includes:

the third monitoring module is used for traversing the updating access request queue when the target block is monitored to finish execution and the access request queue is updated; the updating access request queue is updated based on the access request queue, and comprises a queue task request and a new task request which does not belong to the transaction execution type;

and the third monitoring module is also used for accessing the blockchain ledger according to the queue task request and the new task request in the update access request queue.

Wherein, above-mentioned data processing apparatus still includes:

and the queue updating module is used for adding the new task request into the tail of the access request queue to obtain an updated access request queue if the new task request which does not belong to the transaction execution type is received in the execution process of the target block.

The number of the queue task requests is M; the number of kinds of task types of the M queue task requests is at least two; m is a positive integer;

the second monitoring module comprises:

the sequencing unit is used for continuously traversing the access request queue when the execution of the target block is finished, and sequencing the M queue task requests according to the priorities of at least two task types;

The second account access unit is used for sequentially processing the M ordered queue task requests, accessing the blockchain account according to the processed queue task requests to obtain a request access result, and processing the task indicated by the processed queue task requests according to the request access result.

Wherein, above-mentioned data processing apparatus still includes:

and the deleting module is used for deleting the queue task request in the processing completion state from the access request queue when the processed task indicated by the queue task request is processed.

The number of the queue task requests is M; the task types of the M queue task requests comprise a first task type and a second task type; m is a positive integer;

the second monitoring module comprises:

the first request acquisition unit is used for continuing to traverse the access request queue when the execution of the target block is finished, and sequentially acquiring k queue task requests belonging to the first task type from M queue task requests as k first queue task requests; k is a positive integer less than M;

the second request acquisition unit is used for sequentially acquiring s queue task requests belonging to a second task type from the M queue task requests, and taking the s queue task requests as s second queue task requests; s is a positive integer less than M;

And the third account book access unit is used for sequencing the k first queue task requests and the s second queue task requests according to the priorities respectively corresponding to the first task type and the second task type to obtain a task queue to be processed, and accessing the blockchain account book according to the first queue task requests and the second queue task requests in the task queue to be processed.

The number of the queue task requests is M; m is a positive integer;

the second monitoring module comprises:

the waiting time length determining unit is used for continuously traversing the access request queue when the execution end of the target block is monitored, and obtaining waiting processing time length corresponding to each queue task request in the M queue task requests respectively;

the priority determining unit is used for sequencing the M queue task requests according to the priorities corresponding to the queue task requests respectively;

and the fourth account book access unit is used for sequentially processing the M ordered queue task requests and accessing the blockchain account book according to the processed queue task requests.

Wherein, the second monitoring module includes:

the third request acquisition unit is used for continuing to traverse the access request queue when the execution of the target block is finished, and acquiring a target queue task request from the access request queue;

The fifth account book access unit is used for reading the target transaction from the target task request if the task type of the target queue task request is the transaction verification type, and inquiring the blockchain account book according to the target transaction;

the fifth account access unit is further configured to determine that the access result corresponding to the target queue task request is a repeated transaction result if the transaction data identical to the target transaction is queried in the blockchain account;

and the fifth account access unit is further used for determining that the access result corresponding to the target queue task request is a non-repeated transaction result if the transaction data which is the same as the target transaction is not queried in the blockchain account.

Wherein, the second monitoring module includes:

the fourth request acquisition unit is used for continuing to traverse the access request queue when the execution of the target block is finished, and acquiring a target queue task request from the access request queue;

and the sixth account access unit is used for reading the target contract information from the target queue task request if the task type of the target queue task request is the contract query type, querying contract data related to the target contract information in the blockchain account, and taking the contract data as an access result corresponding to the target task request.

Wherein, the second monitoring module includes:

a fifth request acquisition unit, configured to, when it is monitored that the execution of the target block is finished, continue traversing the access request queue, and acquire a target queue task request from the access request queue;

and the seventh account access unit is used for acquiring the data to be uplink according to the target queue task request and storing the data to be uplink into the blockchain account if the task type of the target queue task request is the deposit account type.

In one aspect, a computer device is provided, including: a processor, a memory, a network interface;

the processor is connected to the memory and the network interface, where the network interface is used to provide a data communication network element, the memory is used to store a computer program, and the processor is used to call the computer program to execute the method in the embodiment of the present application.

In one aspect, embodiments of the present application provide a computer readable storage medium having a computer program stored therein, the computer program being adapted to be loaded by a processor and to perform a method according to embodiments of the present application.

In one aspect, the embodiments of the present application provide a computer program product or a computer program, where the computer program product or the computer program includes computer instructions, where the computer instructions are stored in a computer readable storage medium, and where a processor of a computer device reads the computer instructions from the computer readable storage medium, and where the processor executes the computer instructions, so that the computer device performs a method in an embodiment of the present application.

In this embodiment of the present application, when it is monitored that execution of a target block starts, processing of an access request queue for a blockchain ledger may be suspended, then an execution task request of a transaction execution type may be obtained, the blockchain ledger may be accessed according to the execution task request, an execution access result may be obtained, a transaction in the target block may be executed according to the execution access result, and when it is monitored that execution of the target block ends, the access request queue may be continuously traversed, and access to the blockchain ledger may be requested according to a queue task in the access request queue. The access request queue comprises queue task requests of which task types do not belong to transaction execution types; the execution task request is generated during execution for the target block. According to the method provided by the embodiment of the application, task requests of different task types are distributed to different time periods to be processed, namely in the execution process of the target block, only the execution task requests which are generated in the execution process and belong to the transaction execution type are processed, other queue task requests which are not of the transaction execution type are suspended, and in the time period from the completion of the execution of the target block to the start of the execution of the new target block, the other queue task requests which are not of the transaction execution type are continuously processed, so that the situation that a plurality of functions access a blockchain account book in parallel is improved, the preemption of storage resources by each function can be effectively reduced, and the blockchain performance is improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic block chain node system according to an embodiment of the present disclosure;

FIG. 2 is a schematic diagram of a scenario of a blockchain-based data processing provided in an embodiment of the present application;

FIG. 3 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present disclosure;

FIG. 4a is a block chain transaction processing sequence diagram provided by an embodiment of the present application;

FIG. 4b is a block chain query processing sequence diagram provided by an embodiment of the present application;

FIG. 4c is a block chain ledger call schematic diagram provided in an embodiment of the present application;

FIG. 4d is a schematic diagram of access time distribution provided in an embodiment of the present application;

FIG. 5 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present application;

FIG. 6 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present disclosure;

FIG. 7 is a schematic diagram of a block chain based data processing apparatus according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

The blockchain is a chain data structure taking a block as a basic unit, and the block uses a digital abstract to verify the transaction history acquired before, so that the blockchain is suitable for the requirements of tamper resistance and expandability in a distributed billing scene. Blockchains also refer to distributed accounting techniques implemented by blockchain structures, including distributed consensus, privacy and security protection, point-to-point communication techniques, network protocols, smart contracts, and the like. The goal of the blockchain is to implement a distributed data logging ledger that allows only additions and not deletions. The basic structure of the ledger floor is a linear linked list. The linked list is formed by serially connecting blocks, the Hash value of the preceding block is recorded in the following blocks, and whether each block (and the transaction in the block) is legal or not can be rapidly checked by calculating the Hash value. If a blockchain node in the blockchain network proposes to add a new block, a consensus acknowledgement must be made for the block via a consensus mechanism.

It will be appreciated that a Block (Block) is a packet of data carrying transaction data (i.e., transaction traffic) over a blockchain network, and is a data structure that is time stamped and hashed with the previous Block, and that the Block is authenticated by the network's consensus mechanism and determines the transactions in the Block.

It will be appreciated that a hash value, also referred to as an information feature value or a feature value, is generated by converting input data of an arbitrary length into a password through a hash algorithm and performing a fixed output, and cannot retrieve the original input data by decrypting the hash value, which is a one-way encryption function. In the blockchain, each block (except the initial block) contains the hash value of the successor block, which is referred to as the parent block of the current block. Hash value is the potential core foundation and most important aspect in blockchain technology, which preserves the authenticity of the recorded and viewed data, as well as the integrity of the blockchain as a whole.

It will be appreciated that a blockchain system may include a smart contract that is understood in the blockchain system to be a type of code that each node of the blockchain (including the consensus node) may understand and execute, and that may execute any logic and obtain a result. The user can call the intelligent contract which is already deployed on the blockchain by means of the client initiating a transaction service request, then the service node on the blockchain can send the transaction service request to the consensus nodes, and each consensus node on the blockchain can respectively run the intelligent contract. It should be appreciated that one or more intelligent contracts may be included in the blockchain that may be distinguished by an identification number (Identity document, ID) or name, and that the client-initiated transaction request may also carry the identification number or name of the intelligent contract, thereby specifying the intelligent contract that the blockchain is to operate. If the intelligent contract appointed by the client is the contract needing to read the data, each consensus node accesses the local account book to read the data, and finally each consensus node verifies whether the execution results are consistent (i.e. performs consensus), if so, the execution results can be stored in the local account book, and the execution results are returned to the client.

A blockchain network typically consists of numerous blockchain link points through which users interact with the blockchain, i.e., users can send transaction data (business requests) corresponding to transactions into the blockchain. Typically the lifecycle of a transaction comprises:

transaction generation: the user inputs parameters through the DApp, which packages them into transaction data and sends it to some blockchain node.

Transaction broadcasting, namely broadcasting the received transaction data to the whole blockchain network by the blockchain link point.

And (3) transaction verification: after the block chain link point receives the transaction data, the transaction data is checked and repeated from the account book (DB), and the transaction data passing through the verification is checked and enters a transaction pool.

And (3) block packing: the out-block node fetches the transaction data from the transaction pool, packages it into the proposed block, and broadcasts it into the blockchain network. The block-out node is a block chain node responsible for packing the proposed block in the round, the selection of the block-out node is different according to a consensus algorithm, and the blocks are commonly discharged in a round, the blocks are competitive in a calculation, and the like.

Block checking: after the block chain link receives the proposal block, the transaction data in the proposal block is verified, if the transaction is in the transaction pool, the verification is passed, otherwise, the transaction needs to be checked and re-checked.

Block consensus: the blockchain node votes on the received proposal block according to the block check result, and when the blockchain node receives the majority vote and meets the consensus passing condition, the proposal block is approved and submitted.

Block execution: transaction data in the approved proposal block is performed.

Deposit account book: the proposal area, the transaction data and the transaction execution result are stored in the blockchain account book.

Referring to fig. 1, fig. 1 is a schematic structural diagram of a blockchain node system according to an embodiment of the present application. The blockchain node system as shown in fig. 1 may correspond to a blockchain network that may include, but is not limited to, a blockchain network to which a federated chain corresponds. The blockchain node system refers to a system for sharing data between blockchain nodes, and the blockchain node system may include a plurality of blockchain nodes, and the plurality of blockchain nodes may specifically include a blockchain node 10a, a blockchain node 10b, a blockchain node 10c, blockchain nodes 10d, …, and a blockchain node 10n. Each node can receive data sent by the outside during normal operation, perform block uplink processing based on the received data, and also can send the data to the outside. To ensure data interworking between the various nodes, there may be a data connection between each node, for example, a data connection between the blockchain node 10a and the blockchain node 10b, a data connection between the blockchain node 10a and the blockchain node 10c, and a data connection between the blockchain node 10b and the blockchain node 10 c.

It will be appreciated that data or block transfer may be performed between the blockchain nodes via the data connections described above. The blockchain network may implement data connection between blockchain nodes based on node identifiers, and for each blockchain node in the blockchain network, each blockchain node may store node identifiers of other blockchain nodes having a connection relationship with itself, so as to broadcast the acquired data or generated blocks to other blockchain nodes according to the node identifiers of the other blockchain nodes, for example, the blockchain node 10a may maintain a node identifier list as shown in table 1, where the node identifier list stores node names and node identifiers of the other nodes:

TABLE 1

Node name	Node identification
		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

The node identifier may be any of a protocol (Internet Protocol, IP) address for interconnection between networks, and any other information that can be used to identify a node in a blockchain network, and the IP address is only illustrated in table 1. For example, the blockchain node 10a may send information (e.g., a block) to the blockchain node 10b through the node identification 117.116.189.145, and the blockchain node 10b may determine that the information was sent by the blockchain node 10a through the node identification 117.114.151.174.

In a blockchain, a block must be consensus-passed through consensus nodes in the blockchain network before the block is uplink, and the block can be added to the blockchain after the consensus passes. It will be appreciated that when a blockchain is used in some contexts of a government or commercial establishment, not all participating nodes in the blockchain (i.e., blockchain nodes in the blockchain node system described above) have sufficient resources and necessity to become consensus nodes of the blockchain. For example, in the blockchain node system shown in fig. 1, blockchain node 10a, blockchain node 10b, blockchain node 10c, and blockchain node 10d may be considered as consensus nodes in the blockchain node system. The consensus nodes in the block chain node system participate in consensus, namely, the block (comprising a batch of transactions) is subjected to consensus, and the block is generated and voted; while non-consensus nodes do not participate in consensus, but will help propagate block and vote messages, and synchronize status with each other, etc.

It should be understood that the above data connection is not limited to a connection manner, and may be directly or indirectly connected through a wired communication manner, may be directly or indirectly connected through a wireless communication manner, and may also be connected through other connection manners, which is not limited herein.

It is understood that the blockchain-based data processing method provided by the embodiments of the present application may be performed by a computer device, including but not limited to the blockchain node (which may be a terminal or a server) described above. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligence platforms. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, and the like.

It is to be appreciated that embodiments of the present application may be applied to a variety of scenarios including, but not limited to, cloud technology, artificial intelligence, intelligent transportation, assisted driving, and the like. For example, the block link point system may perform consensus on some driving behavior data, road track data, and the like sent by the vehicle-mounted terminal, and store the consensus on the vehicle-mounted terminal after the consensus passes.

As shown in FIG. 1, blockchain nodes (e.g., blockchain node 10 a) in a blockchain node system all need to access a blockchain ledger when performing functionally related processes such as transaction reconciliation, contract query, blockexecution, etc. on transactions. While the blockchain node 10a may need to process thousands of transactions requiring uplink at the same time in the running process, the progress of the uplink of the transactions is different, the functions provided by the blockchain node 10a for different transactions are different, and there may be thousands of task requests for accessing the blockchain ledger at the same time, where the task requests may include query requests generated for the blockchain ledger, and the task types of the task requests may be different, and may be a transaction execution type, a transaction check type, a contract query type, and so on. The task request of the transaction execution type is a query request generated for the transaction contained in the block in the process of executing the block, and the query request is used for acquiring transaction data corresponding to the transaction so as to execute the transaction; the task request of transaction check type is a query request generated for a transaction in the process of transaction verification and used for confirming whether the transaction is repeatedly uplink; the task request of the contract query type is a query request generated for a contract for retrieving contract data associated with the contract. In order to avoid the situation that each function cannot smoothly operate due to the preemptive access to the blockchain ledger of task requests of different task types, the blockchain node 10a can dynamically adjust the time of the task requests of each task type to access the blockchain ledger, so that the function corresponding to each task type monopolizes the storage resource corresponding to the blockchain ledger as much as possible, thereby effectively reducing the resource waste caused by preempting the storage resource for each function and improving the execution efficiency.

The specific process of the blockchain node 10a dynamically adjusting the time for a task request of each task type to access the blockchain ledger may be: after receiving the target block, the blockchain node 10a performs block verification, block consensus, block execution, account deposit, and other processes on the target block. When the blockchain node 10a monitors that the execution of the target block starts, the processing of the target access request queue for the blockchain ledger is suspended, wherein the target access request queue contains queue task requests waiting to be processed, and the task types of the queue task requests do not belong to the transaction execution types. Then, the blockchain node 10a will acquire the execution task request belonging to the transaction execution type generated in the execution process of the target block, access the blockchain ledger according to the execution task request, obtain the access result, and execute the transaction in the target block according to the access result. Until the blockchain node 10a monitors that the target blockexecution is completed, the blockchain node 10a continues to traverse the target access request queue, and then requests to access the blockchain ledger according to the queue tasks in the target access request queue.

For a better understanding of the above process, please refer to fig. 2, fig. 2 is a schematic diagram of a scenario of a blockchain-based data processing provided in an embodiment of the present application. The blockchain ledger in the blockchain node system is a de-centralized distributed database, which is formed by connecting databases to form a large distributed database, and each database has the same authority and can view and store all data. Thus, each blockchain node in the blockchain node system may have a database, which may be referred to as a blockchain ledger for that blockchain node, and each blockchain node is responsible for maintaining and managing its own blockchain ledger, and writing all commonly-identified transactions and transaction-related data on the blockchain into the blockchain ledger. The blockchain node 20 shown in fig. 2 may be any blockchain node in the blockchain node system of the embodiment described above with respect to fig. 1, such as blockchain node 10b. The blockchain node 20 corresponds to the blockchain ledger 201, and the blockchain node 20 can obtain all transactions and transaction related data from the blockchain ledger 201, because when the blockchain node 20 completes execution of a block, the processing of storing the block and the execution result into the ledger is performed.

As shown in fig. 2, in the running process of the blockchain node 20, multiple transactions often need to be processed simultaneously, and because the time for initiating these transactions is different, the processing progress of the blockchain node 20 for uplink to different transactions is different, the access requirement of the blockchain node 20 for the blockchain ledger under different processing progress is different, and the task types corresponding to the generated task requests are different. For example, when the blockchain node 20 performs a transaction verification on the transaction a, it needs to determine whether the transaction a exists in the blockchain ledger, and the blockchain node 20 generates a task request a with a task type of a transaction verification type; alternatively, when the blockchain node 20 needs to acquire the contract data of the contract B, a task request B with a task type of a contract query type may be generated; alternatively, the blockchain node 20 generates a task request C having a task type of transaction execution type, and so on, when processing the transaction C during execution of the block. Because the blockchain node 20 processes multiple transactions in parallel, the execution of task requests also requires time, and therefore, at the same time, the blockchain node 20 may have multiple task requests waiting to be processed, and the number of task requests may exceed the number of task requests that the blockchain node 20 can process in parallel, so that the blockchain node 20 may add task requests that are not of the type of transaction execution as queue task requests into the access request queue 201, and then sequentially process the queue task requests in the access request queue 201. As shown in fig. 2, the access request queue 201 includes a queue task request 2011, a queue task request 2012, a queue task request 2013, queue task requests 2014, …, and a 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 the queue task requests simultaneously, and will process part of the queue task requests in parallel, if the blockchain node 20 is processing the queue task request 2011 and the queue task request 2012 in parallel at this time, the rest of the queue task requests are in a waiting state, and the queue task requests 2011 and 2012 are processed, and the blockchain node 20 processes the queue task request 2013 and the queue task request 2014 sequentially.

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 the processing of the access request queue 201 is suspended when the blockchain node 20 processes the execution task request whose task type belongs to the transaction execution type. As shown in FIG. 2, each time a block to be uplinked is received by blockchain node 20, it is monitored as a target block, and if the blockchain node 20 receives the target block 202 at this time, when blockchain node 20 monitors that the execution of the target block 202 begins, it suspends processing the access request queue 201 for blockchain ledger 200. Optionally, when the target block 202 starts executing, in the access request queue 201, the queue task request 2011 and the queue task request 2012 are being processed, and the blockchain node 20 may process the queue task request 2011 and the queue task request 2012 first, and then the remaining queue task requests in the access request queue 201 are not processed. The processing of the access request queue 201 is stopped to process the task request with the task type of transaction execution type generated in the execution process of the target block 202, specifically, the target block 202 includes a plurality of transactions, and when the blockchain node system where the blockchain node 20 is located has passed the consensus of the target block 202, the blockchain node 20 executes the target block 202. Wherein, executing the target block 202 includes executing one or more transactions included in the target block 202, when the blockchain node 20 executes a transaction in the target block 202, it may need to acquire data related to the transaction to execute the transaction, and a task execution request is generated at this time, and when the blockchain node 20 processes the task execution request, it may acquire data required for the transaction from the blockchain ledger 200. As shown in fig. 2, during the execution of the target block 202, the blockchain node 20 obtains the execution task requests belonging to the transaction execution type, that is, the execution task requests 2021, 2022, …, and n, the blockchain node 20 sequentially processes the execution task requests according to the maximum concurrent processing number, and when the blockchain node 20 processes the execution task requests related to the target block 202, the blockchain node 20 does not process the queue task requests in the access request queue 201, so that it is possible to avoid that the blockchain node 20 frequently switches the access manner to the blockchain ledger due to the inconsistency of the task types, thereby causing a conflict and further resulting in low operation efficiency. As shown in fig. 2, until the blockchain node 20 listens to the end of execution of the target block 202, the blockchain node 20 continues to traverse the access request queue 201, and if the blockchain node 20 pauses processing the access request queue 201 after processing the queue task request 2011 and the queue task request 2012, the blockchain node 20 starts processing from the queue task request 2013.

Further, referring to fig. 3, fig. 3 is a flow chart of a data processing method based on a blockchain according to an embodiment of the present application. The data processing method may be performed by a blockchain node (e.g., any of the blockchain nodes in the blockchain node system of the embodiment described above with respect to fig. 1). The present data processing method will be described below by taking the block link point execution as an example. The data processing method based on the blockchain at least comprises the following steps of S101 to S103:

step S101, when the execution start of a target block is monitored, suspending processing of an access request queue aiming at a block chain account book; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type.

Specifically, in the running process of the blockchain link point, the blockchain account is required to be accessed in the steps of executing the transaction, checking the weight of the transaction, storing the account and the like in the transaction processing process, and in addition, the blockchain node is required to be accessed in response to the query request initiated by the user. The requests for accessing the blockchain ledger may be referred to as task requests, and the task types of the task requests generated in different processes may be different, and the task types of the task requests may include transaction execution types, transaction verification types, contract query types, deposit ledger types, and the like. To better avoid preemptive access to blockchain accounts for task requests of different task types, blockchain nodes may dynamically adjust the time at which task requests of various task types access the blockchain accounts.

Specifically, when the block chain node executes the block, the block chain node generates a plurality of transaction execution task requests for the transaction execution type, and when the block chain node executes the block, the block chain node generates a plurality of transaction execution task requests for the transaction execution type in a short time, so that the block chain node can suspend the processing of task requests of other task types in the process of executing the block, and only process the execution task requests. In a large blockchain node system, the blockchain node may receive a large number of task requests, far exceeding the number of task requests that the blockchain node can concurrently execute, so that the blockchain node can add task requests that are not of the transaction execution type as queue task requests into the access request queue, and then when no block is executed in the blockchain node, the blockchain node processes the access request queue sequentially. In short, when the blockchain node does not execute the block, processing a queue task request in an access request queue, and accessing a blockchain ledger according to the queue task request; while executing the block, the queue task requests in the access request queue are suspended and only the execution task requests are processed.

Specifically, each time a new proposed block is received by a blockchain node, or the blockchain node packages a new proposed block by itself as a block-out node, the blockchain node listens for it as a target block. When the target block execution starts is monitored, the blockchain node pauses processing the access request queue for the blockchain ledger. The monitoring of the target block may be implemented by a flow control unit, where the flow control unit may be a process component or application software.

Optionally, when it is monitored that the target block starts to execute, the blockchain node may search the 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; when the target queue task request processing is completed, processing of the access request queue is suspended. In short, the queue task requests which have been started to be processed in the access request queue can be processed continuously, and the queue task requests which have not been processed can be stopped to be processed first.

Step S102, an execution task request belonging to a transaction execution type is acquired, the blockchain ledger is accessed according to the execution task request, an execution access result is obtained, and the transaction in the target block is executed according to the execution access result; the execution task request is generated during execution for the target block.

Specifically, the target block often includes a plurality of transactions, when the target block is executed by the blockchain node, the blockchain node actually executes the plurality of transactions in the target block, and when part of the transactions are executed, historical transaction data needs to be acquired first, and then the execution can be completed, and at this time, the blockchain ledger needs to be accessed to acquire the historical transaction data. Assuming that the transaction 1 is that the first party transfers 10 yuan to the second party through the account of the first party, the account balance of the first party before transferring is historical transaction data, an execution task request 1 for reading the account balance of the first party is generated in the process of executing the transaction 1, the blockchain node acquires the execution task request 1, accesses the blockchain account according to the execution task request 1, reads the account balance of the first party, and if 20 is assumed, the blockchain node returns 20 as an execution access result, the blockchain node 20 can continue to execute the transaction 1 according to the execution access result, and the transaction execution result 1 for the transaction 1 can be 20-10=10 yuan, namely 10 yuan remains on the account of the first party after executing the transaction 1.

And step S103, when the target block execution is monitored to be finished, continuing to traverse the access request queue, and requesting to access the blockchain ledger according to the queue task in the access request queue.

Specifically, in the execution process of the target block, no new task request which does not belong to the transaction execution type is generated, and the access request queue is not updated. And when the target block is monitored to finish execution and the access request queue is not updated, continuing to traverse the access request queue, and requesting to access the blockchain ledger according to the queue task in the access request queue.

Optionally, in the execution process for the target block, if a new task request not belonging to the transaction execution type is received, the new task request is added to the tail of the access request queue, so as to obtain an updated access request queue. Assuming that the access request queue sequentially includes a queue task request 1, queue task requests 2 and … and a queue task request n, the target block is executing at this time, but the blockchain node acquires a new task request k which does not belong to the transaction execution type, and the blockchain node takes the new task request k as a queue task request n+1, and then adds the queue task request n+1 into the access request queue to obtain an update access request queue, where the update access request queue incidentally includes the queue task request 1, the queue task requests 2 and …, the queue task request n and the queue task request n+1. Then, when the block chain link point monitors that the execution of the target block is finished and the access request queue is updated, traversing the update access request queue; and accessing the blockchain ledger according to the queue task request and the new task request in the update access request queue. It will be appreciated that updating the access request queue is based on updating the access request queue, which includes queue task requests and new task requests that are not of the transaction execution type.

By adopting the method provided by the embodiment of the application, when the execution start of the target block is monitored, the processing of the access request queue aiming at the blockchain ledger is suspended, then the execution task request of the transaction execution type is acquired, the blockchain ledger is accessed according to the execution task request, the execution access result is obtained, the transaction in the target block is executed according to the execution access result, when the execution end of the target block is monitored, the access request queue is continuously traversed, and the blockchain ledger is requested to be accessed according to the queue task in the access request queue. By dispersing task requests of different task types into different time periods for processing, namely, in the execution process of a target block, only processing execution task requests which are generated in the execution process and belong to transaction execution types, suspending other queue task requests which are not of transaction execution types, and continuing to process other queue task requests which are not of transaction execution types in the time period from the completion of the execution of the target block to the start of the execution of a new target block, the situation that a plurality of functions access a block chain account book in parallel can be improved, the preemption of each function on storage resources can be effectively reduced, and the block chain performance can be improved.

The transaction processing process in the blockchain mainly includes steps of transaction propagation, transaction pool verification, transaction packaging into blocks, block consensus, transaction execution, and account deposit, etc., and for ease of understanding, please refer to fig. 4a, fig. 4a is a blockchain transaction processing sequence diagram provided in the embodiment of the present application. As shown in fig. 4a, the end device may generate a transaction (also referred to as transaction data) through a de-centralization application, then the end device may send the transaction to a certain blockchain node in the blockchain network, such as blockchain node a, which may then broadcast the transaction to the remaining blockchain nodes in the blockchain network, namely blockchain node B and blockchain node C. Each blockchain node in the blockchain network needs to perform transaction verification on the acquired transaction. If the transaction fails, ignoring the transaction; and if the transaction is successful, storing the transaction into a transaction pool. Then, the out-block node (which may be any one of the blockchain nodes in the blockchain network and may be selected by a polling mechanism) needs to acquire one or more transactions from the transaction pool, then generates a proposed block according to the one or more transactions, and assuming that the blockchain node C is the out-block node, after generating the proposed block, the blockchain node C broadcasts the proposed block to the rest of the blockchain nodes, and then each blockchain node performs a block check on the proposed block to obtain a block check result, and if the block check result is a check pass result, the block processing node of the blockchain node generates a consensus pass vote for the proposed block; if the block check result is a check failure result, the block processing node of the blockchain node generates a consensus failure vote for the proposed block. The voting result for each blockchain node is then broadcast to the remaining blockchain nodes. When the number of blockchain nodes that generated a consensus pass vote for the proposed block exceeds a consensus threshold, then a consensus pass for the proposed block is determined. And finally, after each blockchain node confirms that the common knowledge of the proposed block passes, executing one or more transactions in the proposed block to obtain a transaction execution result, and writing the proposed block and the transaction execution result into a blockchain ledger.

Specifically, in the blockchain transaction processing process of fig. 4a, the blockchain ledger is accessed by both transaction execution and transaction verification, wherein the transaction verification is a way in the transaction verification process to confirm whether the transaction has been stored in the blockchain ledger. Queries against blockchain ledgers include contract queries in addition to the processes described above. For ease of understanding, please refer to fig. 4b together, fig. 4b is a block chain query processing sequence diagram provided in an embodiment of the present application. As shown in fig. 4b, the terminal device generates a query request through the decentralizing application, the block link point responds to the query request, and invokes a query contract in the intelligent contract, then accesses the block chain ledger according to the indication of the query contract, queries the required data, then returns the required data to the block chain ledger, obtains the contract execution result of the query contract according to the data returned by the block chain ledger, and then returns the contract execution result to the decentralizing application. Wherein the query request includes a transaction query, a contract query, a block query, and the like. It will be appreciated that in the process of depositing the ledgers of fig. 4a, the blockchain node also needs to access the blockchain ledgers, but more so, writes to the blockchain ledgers, i.e. writes new data to the blockchain ledgers.

As mentioned above, the time of the task request accessing the blockchain ledger of each transaction execution type can be dynamically adjusted by the flow control unit, please refer to fig. 4c, fig. 4c is a schematic diagram of the blockchain ledger call provided in the embodiment of the present application. As shown in fig. 4c, when performing operations such as transaction verification, transaction execution, contract inquiry and storage of blocks or contract data, the blockchain node may first search in the cache when the related data needs to be acquired, and if the related data does not exist in the cache, the blockchain node needs to search in the blockchain ledger. The task requests corresponding to the operations reach the flow control unit, and then the flow control unit decides which task request is processed first. The flow control unit can operate and process the task request according to different operations corresponding to the task request, namely different task types, for example, when the block chain node starts to execute the target block after the target block is commonly passed, the flow control unit processes the transaction execution corresponding task request; when the blockchain node confirms that the newly received transaction is legal, the flow control unit can process a task request corresponding to the transaction verification of the legal new transaction at the time except the execution target block; the flow control unit may respond to the contract query request at a time other than execution of the target block.

In short, the transaction execution has the highest priority, when the transaction execution is performed, other account access functions are suspended, after the current block is processed, the next block needs to come, at this time, access of other account data, such as contract inquiry, transaction duplication, data storage, etc., can be performed, and for convenience of understanding, please refer to fig. 4d together, fig. 4d is a schematic view of access time distribution provided in the embodiment of the present application. As shown in fig. 4d, through the flow control unit, the access flow of the block chain link point to the account book data can be dispersed into different time slices, so that when each operation is performed by the block chain node, the storage resources can be acquired as much as possible, the processing speed can be faster, and therefore, the overall performance of the block chain can be improved.

Further, referring to fig. 5, fig. 5 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present application. The data processing method may be performed by a blockchain node (e.g., any of the blockchain nodes in the blockchain node system of the embodiment described above with respect to fig. 1). The present data processing method will be described below by taking the block link point execution as an example. The blockchain-based data processing method at least includes the following steps S201 to S203:

Step S201, when the execution start of a target block is monitored, the processing of an access request queue aiming at a block chain account book is suspended; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type.

Step S202, an execution task request belonging to a transaction execution type is acquired, the blockchain ledger is accessed according to the execution task request, an execution access result is obtained, and the transaction in the target block is executed according to the execution access result; the execution task request is generated during execution for the target block.

Specifically, the implementation process of step S201 and step S202 may refer to the specific descriptions of step S102-step S102, and will not be described herein.

Step S203, when the target block execution is monitored to be finished, continuing to traverse the access request queue, and accessing the blockchain ledger according to a queue task request in the access request queue; the number of the queue task requests is M; m is a positive integer.

Specifically, when the blockchain node processes the M queue task requests in the access request queue, it may also comprehensively consider which queue task requests are processed with priority according to task types, priorities, waiting time and the like of the M queue task requests.

In one possible embodiment, the number of types of task types of the M queue task requests is at least two, when it is monitored that the target block execution is finished, the access request queue is continuously traversed, and according to a specific implementation process of the queue task request access block chain ledger in the access request queue, the specific implementation process may be: when the execution of the target block is monitored to be finished, continuing to traverse the access request queue, and sequencing the M queue task requests according to the priorities of at least two task types; and sequentially processing the M ordered queue task requests, accessing the blockchain ledger according to the processed queue task requests to obtain a request access result, and processing the task indicated by the processed queue task requests according to the request access result. For example, the blockchain node may process 2 queue task requests at most concurrently, and the access request queue includes four queue task requests, i.e., queue task request 1, queue task request 2, queue task request 3, and queue task request 4, where the task types of queue task request 1 and queue task request 4 are contract query types, the task types of queue task request 2 and queue task request 3 are transaction verification types, and if the contract query types have a higher priority than the transaction verification types, the blockchain node performs sorting processing on the four queue task requests, and then the four queue task requests after sorting are obtained as queue task request 1, queue task request 4, queue task request 2, and queue task request 3, and then the blockchain node processes queue task request 1 and queue task request 4 first, and then processes queue task request 2 and queue task request 3.

In a possible embodiment, the task types of the M queue task requests include a first task type and a second task type, and when it is monitored that the target block execution is finished, the access request queue is continuously traversed, and according to a specific implementation process of the queue task request access blockchain ledger in the access request queue, the specific implementation process may be: when the execution of the target block is monitored to be finished, continuing to traverse the access request queue, and sequentially acquiring k queue task requests belonging to the first task type from M queue task requests to serve as k first queue task requests; k is a positive integer less than M; sequentially obtaining s queue task requests belonging to the second task type from the M queue task requests, and taking the s queue task requests as s second queue task requests; s is a positive integer less than M; and sequencing the k first queue task requests and the s second queue task requests according to priorities respectively corresponding to the first task type and the second task type to obtain a task queue to be processed, and accessing the blockchain ledger according to the first queue task requests and the second queue task requests in the task queue to be processed. The queue task requests in the access request queue are ordered according to the early and late order of time, 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 a queue task request 1 belonging to a first task type, a queue task request 2 belonging to a second task type, a queue task request 3 belonging to the first task type, a queue task request 4 belonging to the second task type, queue task requests 5 and … … belonging to the first task type, and a queue task request m belonging to the second task type, and it is obvious that after the block chain node processes the queue task requests of the first task type, the processing efficiency is not high, so that the block chain node can firstly acquire 2 queue task requests belonging to the first task type, namely the queue task request 1 and the queue task request 3 belonging to the first task type in order, then acquire 2 queue task requests belonging to the second task type in order, namely the queue task request 2 and the queue task request 2 belonging to the second task type in order, and the second task request 4 is assumed to be the first task type, and the first task request is processed by the block chain node after the first task request is processed by the first task type, and the second task request is processed by the first queue type, and the block chain node is not high in processing efficiency: 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 queues in order.

In a possible embodiment, when it is monitored that the execution of the target block is finished, the access request queue is continuously traversed, and according to a specific implementation process of the queue task request access block chain ledger in the access request queue, the specific implementation process may be: when the execution of the target block is monitored to be finished, continuing to traverse the access request queue, and acquiring waiting processing time length corresponding to each queue task request in the M queue task requests; determining the priority corresponding to each queue task request according to the waiting time range to which the waiting time belongs, wherein different priorities map different waiting time ranges; sequencing the M queue task requests according to the priorities corresponding to the queue task requests respectively; and sequentially processing the M ordered queue task requests, and accessing the blockchain ledger according to the processed queue task requests. For example, the access request queue includes a queue task request 1, a queue task request 2, a queue task request 3, a queue task request 4 and a queue task request 5, where the waiting processing time of the queue task request 1 is 18 seconds, the waiting processing time of the queue task request 2 is 65 seconds, the waiting processing time of the queue task request 3 is 75 seconds, the waiting processing time of the queue task request 4 is 5 seconds, the waiting processing time of the queue task request 5 is 45 seconds, it is assumed that the waiting processing time is within 30 seconds and corresponds to a first priority, the waiting processing time is within 30 seconds to 60 seconds and corresponds to a second priority, the waiting processing time exceeds 60 seconds and corresponds to a third priority, and if the waiting processing time is longer, the priority level is higher, the M queue task requests are reordered to obtain: queue task request 2, queue task request 3, queue task request 5, queue task request 1, and queue task request 4.

Optionally, when the task indicated by the processed queue task request is processed, the queue task request in the processing completion state is deleted from the access request queue.

By adopting the method provided by the embodiment of the application, the queue task requests of different task types are processed by the blockchain node in a sequencing way, so that the queue task requests with high priority can be processed preferentially, and the queue task requests with the same task type can be processed together, thereby prompting the running efficiency of the blockchain node.

Further, referring to fig. 6, fig. 6 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present application. The data processing method may be performed by a blockchain node (e.g., any of the blockchain nodes in the blockchain node system of the embodiment described above with respect to fig. 1). The present data processing method will be described below by taking the block link point execution as an example. The blockchain-based data processing method at least includes the following steps S301 to S303:

step S301, when the execution start of a target block is monitored, suspending processing of an access request queue aiming at a block chain account book; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type.

Step S302, an execution task request belonging to a transaction execution type is acquired, the blockchain ledger is accessed according to the execution task request, an execution access result is obtained, and the transaction in the target block is executed according to the execution access result; the execution task request is generated during execution for the target block.

Specifically, the implementation process of step S301 and step S302 may refer to the specific descriptions of step S102-step S102, and will not be described herein.

Step S303, when it is monitored that the execution of the target block is finished, continuing to traverse the access request queue, obtaining a target queue task request from the access request queue, and accessing the blockchain ledger according to a task type of the target queue task request.

Specifically, if the task type of the target queue task request is a transaction verification type, reading target transaction from the target task request, and inquiring the blockchain ledger according to the target transaction; if the transaction data which is the same as the target transaction is queried in the blockchain account book, determining that the access result corresponding to the target queue task request is a repeated transaction result; if the transaction data which is the same as the target transaction is not queried in the blockchain ledger, determining that the access result corresponding to the target queue task request is a non-repeated transaction result. The purpose of the verification of the transaction is to prevent duplication of the uplink of the transaction.

Specifically, if the task type of the target queue task request is a contract query type, target contract information is read from the target queue task request, contract data associated with the target contract information is queried in the blockchain ledger, and the contract data is used as an access result corresponding to the target task request. Reference may be made specifically to the description of the embodiment corresponding to fig. 4b, and no further description is given here.

Specifically, if the task type of the target queue task request is the deposit book type, the data to be uplink is obtained according to the target queue task request, and the data to be uplink is stored in the blockchain account book.

Fig. 7 is a schematic structural diagram of a data processing apparatus based on a blockchain according to an embodiment of the present application. The data processing apparatus may be a computer program (including program code) running on a computer device, for example the data processing apparatus is an application software; the device can be used for executing corresponding steps in the data processing method provided by the embodiment of the application. As shown in fig. 7, the data processing apparatus 1 may include: a first listening module 11, an access module 12 and a second listening module 13.

A first monitoring module 11, configured to suspend processing of an access request queue for a blockchain ledger when it is monitored that execution of a target block starts; the access request queue comprises a queue task request; the task type of the queue task request does not belong to the transaction execution type;

The access module 12 is configured to obtain an execution task request belonging to a transaction execution type, access a blockchain ledger according to the execution task request, obtain an execution access result, and execute a transaction in a target block according to the execution access result; the execution task request is generated during execution for the target block;

and the second monitoring module 13 is used for continuing to traverse the access request queue when the target block execution is monitored to be finished, and requesting to access the blockchain ledger according to the queue task in the access request queue.

The specific implementation manner of the first monitoring module 11, the access module 12, and the second monitoring module 13 may be referred to the description of step S101 to step S103 in the embodiment corresponding to fig. 3, which will not be described herein.

Referring to fig. 7, the first listening module 11 may include: the processing request determination unit 1101 and the suspension unit 1102.

A processing request determining unit 1101, configured to, when it is monitored that the target block execution starts, find a queue task request being processed in an access request queue for a blockchain ledger, and determine the queue task request being processed as a target queue task request;

a suspending unit 1102, configured to suspend processing of the access request queue when the target queue task request processing is completed.

For specific implementation manners of the processing request determining unit 1101 and the suspending unit 1102, reference may be made to the description of step S101 in the embodiment corresponding to fig. 3, and the description will not be repeated here.

Referring to fig. 7, the second listening module 13 may include: listening access unit 1301 and first ledger access unit 1302.

A monitor access unit 1301, configured to, when it is monitored that execution of the target block is finished and the access request queue is not updated, continue traversing the access request queue;

a first ledger access unit 1302, configured to request access to a blockchain ledger according to a queue task in an access request queue;

the specific implementation manner of the snoop access unit 1301 and the first ledger access unit 1302 may refer to the description of step S103 in the embodiment corresponding to fig. 3, which will not be described herein.

Referring to fig. 7, the data processing apparatus 1 further includes: a third listening module 14.

A third monitoring module 14, configured to traverse the update access request queue when it is monitored that the target block is executed and the access request queue is updated; the updating access request queue is updated based on the access request queue, and comprises a queue task request and a new task request which does not belong to the transaction execution type;

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.

The specific implementation of the third monitoring module 14 may be described with reference to the optional embodiment of step S103 in the embodiment corresponding to fig. 3, which will not be described herein.

Referring to fig. 7, the data processing apparatus 1 further includes: a queue update module 15.

The queue updating module 15 is configured to, during execution of the target block, add a new task request that is not of the transaction execution type to the tail of the access request queue to obtain an updated access request queue if the new task request is received.

The specific implementation of the queue updating module 15 may be described with reference to the optional embodiment of step S103 in the embodiment corresponding to fig. 3, which will not be described herein.

referring to fig. 7, the second listening module 13 may include: ordering element 1303 and second ledger access element 1304.

The ordering unit 1303 is configured to, when it is monitored that the execution of the target block is finished, continue traversing the access request queue, and perform ordering processing on the task requests of the M queues according to priorities of at least two task types;

The second ledger access unit 1304 is configured to process the M ordered queue task requests in order, 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 requests according to the request access result.

For a specific implementation manner of the sorting unit 1303 and the second ledger access unit 1304, reference may be made to the description of step S203 in the embodiment corresponding to fig. 5, and the description will not be repeated here.

Wherein the data processing apparatus 1 further comprises: the module 16 is deleted.

And a deleting module 16, configured to delete the queue task request in the processing completion state from the access request queue when the task indicated by the processed queue task request is processed.

For a specific implementation of the deletion module 16, reference may be made to the optional description of step S203 in the embodiment corresponding to fig. 5, which will not be repeated here.

referring to fig. 7, the second listening module 13 may include: first request acquiring unit 1305, second request acquiring unit 1306, and third ledger access unit 1307.

A first request obtaining unit 1305, configured to, when it is monitored that the execution of the target block is finished, continue traversing the access request queue, and sequentially obtain 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;

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

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 priorities corresponding to the first task type and the second task type, obtain a task queue to be processed, and access the blockchain ledger according to the first queue task requests and the second queue task requests in the task queue to be processed.

The specific implementation manner of the first request acquiring unit 1305, the second request acquiring unit 1306 and the third ledger access unit 1307 may refer to the description of step S203 in the embodiment corresponding to fig. 5, which will not be described herein.

The number of the queue task requests is M; m is a positive integer;

Referring to fig. 7, the second listening module 13 may include: wait time period determining unit 1308, priority determining unit 1309, and fourth ledger access unit 1310.

A waiting time length determining unit 1308, configured to, when it is monitored that the execution of the target block is finished, continue traversing the access request queue, and obtain waiting time lengths corresponding to each queue task request in the M queue task requests respectively;

a priority determining unit 1309, configured to sort the M queue task requests according to priorities corresponding to each queue task request respectively;

fourth ledger access unit 1310, configured to process the M ordered queue task requests in order, and access the blockchain ledger according to the processed queue task requests.

The specific implementation manner of the waiting time determining unit 1308, the priority determining unit 1309, and the fourth ledger access unit 1310 may refer to the description of step S203 in the embodiment corresponding to fig. 5, which will not be described in detail here.

Referring to fig. 7, the second listening module 13 may include: third request acquisition element 1311 and fifth ledger access element 1312.

A third request obtaining unit 1311, configured to, when it is monitored that the execution of the target block is finished, continue traversing the access request queue, and obtain a target queue task request from the access request queue;

The fifth ledger access unit 1312 is configured to read a target transaction from the target task request if the task type of the target queue task request is a transaction verification type, and query the blockchain ledger according to the target transaction;

the fifth account access unit 1312 is further configured to determine that the access result corresponding to the target queue task request is a repeated transaction result if the transaction data identical to the target transaction is queried in the blockchain account;

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 queried in the blockchain ledger.

For a specific implementation manner of third request obtaining unit 1311 and fifth ledger access unit 1312, reference may be made to the description of step S303 in the embodiment corresponding to fig. 6, and details will not be repeated here.

Referring to fig. 7, the second listening module 13 may include: fourth request acquiring unit 1313 and sixth ledger access unit 1314.

A fourth request obtaining unit 1313, configured to, when it is monitored that the target block execution ends, continue traversing the access request queue, and obtain a target queue task request from the access request queue;

Sixth ledger access unit 1314, configured to read the 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 an access result corresponding to the target task request.

For a specific implementation manner of fourth request acquiring unit 1313 and sixth ledger access unit 1314, reference may be made to the description of step S303 in the embodiment corresponding to fig. 6, which will not be repeated here.

Referring to fig. 7, the second listening module 13 may include: fifth request acquiring unit 1315 and seventh ledger access unit 1316.

A fifth request obtaining unit 1315, configured to, when it is monitored that the target block execution ends, continue traversing the access request queue, and obtain a target queue task request from the access request queue;

seventh ledger access unit 1316, configured to obtain data to be uplinked according to the target queue task request if the task type of the target queue task request is a deposit ledger type, and store the data to be uplinked in the blockchain ledger.

For a specific implementation manner of fifth request obtaining unit 1315 and seventh ledger access unit 1316, reference may be made to the description of step S303 in the embodiment corresponding to fig. 6, which will not be repeated here.

Fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 8, the computer device 1000 may include: processor 1001, network interface 1004, and memory 1005, and in addition, the above-described computer device 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display (Display), a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface, among others. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1004 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 also optionally be at least one storage device located remotely from the processor 1001. As shown in fig. 8, an operating system, a network communication module, a user interface module, and a device control application may be included in a memory 1005, which is a type of computer-readable storage medium.

In the computer device 1000 shown in fig. 8, the network interface 1004 may provide a network communication network element; while user interface 1003 is primarily used as an interface for providing input to a user; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

It should be appreciated that the computer device 1000 described in the embodiments of the present application may perform the description of the blockchain-based data processing method in any of the foregoing embodiments corresponding to fig. 3, 5 and 6, and will not be repeated herein. In addition, the description of the beneficial effects of the same method is omitted.

Furthermore, it should be noted here that: the embodiments of the present application further provide a computer readable storage medium, in which the aforementioned computer program executed by the blockchain-based data processing device 1 is stored, and the aforementioned computer program includes program instructions, when the aforementioned program instructions are executed by the aforementioned processor, the aforementioned description of the blockchain-based data processing method in any of the aforementioned embodiments corresponding to fig. 3, 5, and 6 can be executed, and therefore, will not be repeated herein. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the embodiments of the computer-readable storage medium according to the present application, please refer to the description of the method embodiments of the present application.

The computer readable storage medium may be a blockchain-based data processing apparatus provided in any of the foregoing embodiments or an internal storage unit of the computer device, such as a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash card (flash card) or the like, which are provided on the computer device. Further, the computer-readable storage medium may also include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

Furthermore, it should be noted here that: embodiments of the present application also provide a computer program product or computer program comprising 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 executes the computer instructions to cause the computer device to perform the method provided by any of the corresponding embodiments of fig. 3, 5, 6, previously described.

The terms first, second and the like in the description and in the claims and drawings of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the term "include" and any variations thereof is intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, article, or device that comprises a list of steps or elements is not limited to the list of steps or modules but may, in the alternative, include other steps or modules not listed or inherent to such process, method, apparatus, article, or device.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied as electronic hardware, as a computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of network elements in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the solution. The skilled person may use different methods for implementing the described network elements for each specific application, but such implementation should not be considered beyond the scope of the present application.

The foregoing disclosure is only illustrative of the preferred embodiments of the present application and is not intended to limit the scope of the claims herein, as the equivalent of the claims herein shall be construed to fall within the scope of the claims herein.

Claims

1. A blockchain-based data processing method, comprising:

acquiring an execution task request belonging to a transaction execution type, accessing the blockchain ledger according to the execution task request to obtain 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 execution for the target block;

and when the target block is monitored to be executed, continuing to traverse the access request queue, and requesting to access the blockchain ledger according to the queue task in the access request queue.

2. The method of claim 1, wherein suspending processing the access request queue for the blockchain ledger when the target blockchain execution start is monitored, comprises:

When monitoring that the execution of the target block starts, searching a queue task request which is being processed in an access request queue aiming at a blockchain ledger, and determining the queue task request which is being processed as the target queue task request;

and suspending processing of the access request queue when the target queue task request processing is completed.

3. The method of claim 1, wherein when the target block execution is detected to be finished, continuing to traverse the access request queue, requesting access to the blockchain ledger according to the queue tasks in the access request queue, comprising:

when the target block is monitored to be executed, and the access request queue is not updated, continuing to traverse the access request queue, and requesting to access the blockchain ledger according to the queue task in the access request queue;

the method further comprises the steps of:

when the target block is monitored to be finished in execution and the access request queue is updated, traversing the update access request queue; the update access request queue is updated based on the access request queue, and comprises the queue task request and a new task request which does not belong to a transaction execution type;

And accessing the blockchain ledger according to the queue task request and the new task request in the update access request queue.

4. A method according to claim 3, further comprising:

and in the execution process aiming at the target block, if a new task request which does not belong to the transaction execution type is received, adding the new task request into the tail of the access request queue to obtain an updated access request queue.

5. The method of claim 1, wherein the number of queued task requests is M; the number of kinds of task types of the M queue task requests is at least two; m is a positive integer;

and when the target block execution is monitored to be finished, continuing to traverse the access request queue, and requesting to access the blockchain ledger according to the queue task in the access request queue, wherein the method comprises the following steps:

when the target block is monitored to be executed, continuing to traverse the access request queue, and sequencing the M queue task requests according to the priorities of at least two task types;

and sequentially processing the M ordered queue task requests, accessing the blockchain ledger according to the processed queue task requests to obtain a request access result, and processing the task indicated by the processed queue task requests according to the request access result.

6. The method as recited in claim 5, further comprising:

when the task indicated by the processed queue task request is processed, deleting the queue task request in a processing completion state from the access request queue.

7. The method of claim 1, wherein the number of queued task requests is M; the task types of the M queue task requests comprise a first task type and a second task type; m is a positive integer;

when the target block is monitored to finish execution, continuing to traverse the access request queue, and sequentially acquiring 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;

sequentially obtaining s queue task requests belonging to the second task type from the M queue task requests, and taking the s queue task requests as s second queue task requests; s is a positive integer less than M;

And sequencing the k first queue task requests and the s second queue task requests according to priorities respectively corresponding to the first task type and the second task type to obtain a task queue to be processed, and accessing the blockchain ledger according to the first queue task requests and the second queue task requests in the task queue to be processed.

8. The method of claim 1, wherein the number of queued task requests is M; m is a positive integer;

when the target block is monitored to be executed, continuing to traverse the access request queue to acquire waiting processing time length corresponding to each queue task request in the M queue task requests;

determining the priority corresponding to each queue task request according to the waiting time range to which the waiting time belongs, wherein different priorities map different waiting time ranges;

sequencing the M queue task requests according to the priorities respectively corresponding to the queue task requests;

And sequentially processing the M ordered queue task requests, and accessing the blockchain ledger according to the processed queue task requests.

9. The method of claim 1, wherein when the target block execution is detected to be finished, continuing to traverse the access request queue, requesting access to the blockchain ledger according to the queue tasks in the access request queue, comprising:

when the target block is monitored to be executed, continuing to traverse the access request queue, and acquiring a target queue task request from the access request queue;

if the task type of the target queue task request is a transaction verification type, reading target transaction from the target task request, and inquiring the blockchain ledger according to the target transaction;

if the transaction data which is the same as the target transaction is queried in the blockchain account book, determining that the access result corresponding to the target queue task request is a repeated transaction result;

and if the transaction data which is the same as the target transaction is not queried in the blockchain ledger, determining that the access result corresponding to the target queue task request is a non-repeated transaction result.

10. The method of claim 1, wherein when the target block execution is detected to be finished, continuing to traverse the access request queue, requesting access to the blockchain ledger according to the queue tasks in the access request queue, comprising:

and if the task type of the target queue task request is a contract query type, reading target contract information from the target queue task request, querying contract data associated with the target contract information in the blockchain ledger, and taking the contract data as an access result corresponding to the target task request.

11. The method of claim 1, wherein when the target block execution is detected to be finished, continuing to traverse the access request queue, requesting access to the blockchain ledger according to the queue tasks in the access request queue, comprising:

And if the task type of the target queue task request is a deposit book type, acquiring data to be uplink according to the target queue task request, and storing the data to be uplink into the blockchain account book.

12. A blockchain-based data processing device, comprising:

the access module is used for acquiring an execution task request belonging to a transaction execution type, accessing the blockchain account book according to the execution task request to obtain 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 execution for the target block;

and the second monitoring module is used for continuing to traverse the access request queue when the target block execution is monitored to be finished, and accessing the blockchain ledger according to the queue task request in the access request queue.

13. A computer device, comprising: a processor, a memory, and a network interface;

the processor is connected to the memory, the network interface for providing data communication functions, the memory for storing program code, the processor for invoking the program code to perform the method of any of claims 1-11.

14. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program adapted to be loaded by a processor and to perform the method of any of claims 1-11.

15. A computer program product comprising computer programs/instructions which, when executed by a processor, are adapted to carry out the method of any one of claims 1-11.