Task processing method and device, equipment and program product

Abstract

The embodiment of the invention discloses a task processing method and device, equipment and a program product, and the method comprises the steps: receiving a first reward return request which is submitted by first computer equipment and carries a first Hash value, a first Merkel tree root and a first Merkel path, hash calculation is carried out on the first Hash value and a first Hash set included in the first Merkel path, the consistency of the first Hash calculation result and the first Merkel tree root is compared to verify the authenticity of the first priority task, and whether the first Hash value exists or not is inquired from historical Hash values of processed historical priority tasks; the method comprises the following steps: freezing a first priority task to verify whether the first priority task is processed preferentially, returning a first reward of the frozen first priority task to a first client when the first priority task is true and not processed preferentially, and returning the reward of priority processing undertaken by an object when the priority task is not processed preferentially within a deadline. And the security of the priority service is improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a task processing method, apparatus, device, and program product. Background Technology

[0002] Blockchain is a distributed ledger technology in the field of information technology. It generally consists of consensus, block and state data storage, cryptographic identity security and other components. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of immutability, traceability and joint maintenance, making it a strong candidate for batch business task processing.

[0003] In related technologies, to help objects process tasks quickly and covertly, services such as task acceleration and Maximum Extractable Value (MEV) services for block builders are provided. The essence of blockchain acceleration services is that objects pay additional fees to specific blockchain nodes, blockchain builders, or other blockchain nodes with accounting rights, causing these nodes to prioritize packaging the object's tasks.

[0004] However, in current blockchain priority channel technology, the priority channel is entirely determined by the corresponding service provider. Even if a task is not processed first, the reward for priority processing submitted by the object will not be returned, thus harming the object's rights. Therefore, there is an urgent need to provide a task processing method to solve the above problems. Summary of the Invention

[0005] This application provides a task processing method, apparatus, device, and program product that can return the priority processing reward undertaken by the object when the priority task is not processed within the time limit, thereby improving the security of priority services and protecting the rights and interests of the object.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions:

[0007] A task processing method, comprising:

[0008] Receive the first reward return request submitted by the first computer device;

[0009] The first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task. The first Merkle root is the Merkle root of a first Merkle tree generated based on the first hash value. The first Merkle path includes proof that the first Merkle root is a first hash set calculated from the first hash value.

[0010] When the first hash calculation result of the first hash set and the first hash value is the first Merkle root, obtain the historical hash value of the processed historical priority task;

[0011] When the historical hash value is different from the first hash value, the first reward corresponding to the first priority task is obtained;

[0012] The frozen first reward is returned to the first client, which is the client that requested the on-chain processing of the first priority task.

[0013] A task processing method, comprising:

[0014] Receive a third priority task sent by a third client, store the third priority task in the priority task pool, and the third priority task carries the third reward corresponding to the third priority task;

[0015] When multiple pending priority tasks obtained from the priority task pool include the third priority task, the sum of the rewards corresponding to each pending priority task is determined to obtain the third total reward.

[0016] A third Merkle tree is generated based on the unprocessed hash value of each of the aforementioned priority tasks.

[0017] Obtain the third Merkle root of the third Merkle tree, and the fifth block corresponding to the third Merkle root;

[0018] Based on the third total reward, the third Merkel root, and the fifth block, construct a third total reward freeze request;

[0019] Send the third total reward freeze request to the third computer device to freeze the third total reward corresponding to the third Merkel root through the third computer device.

[0020] A task processing device, comprising:

[0021] The first receiving unit is used to receive a first reward return request submitted by the first computer device;

[0022] The first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task. The first Merkle root is the Merkle root of a first Merkle tree generated based on the first hash value. The first Merkle path includes proof that the first Merkle root is a first hash set calculated from the first hash value.

[0023] The first acquisition unit is used to acquire the historical hash value of the processed historical priority task when the first hash calculation result of the first hash set and the first hash value is the first Merkle root.

[0024] The second acquisition unit is used to acquire the first reward corresponding to the first priority task when the historical hash value is different from the first hash value.

[0025] The return unit is used to return the frozen first reward to the first client, which is the client that requested the on-chain processing of the first priority task.

[0026] In some embodiments, the first acquisition unit includes:

[0027] The first acquisition subunit is used to acquire the sorting number of each target hash value in the first hash set;

[0028] The first determining subunit is used to determine the target hash value with the smallest sorting number among the target hash values ​​that have not been hashed, according to the sorting number in ascending order, as the hash value to be calculated;

[0029] The second determining subunit is used to determine the first hash calculation result of the first hash value and the hash value to be calculated;

[0030] The first update subunit is used to update the first hash value to the first hash calculation result when there is a target hash value that has not been hashed in the target hash value, and return to execute the step of determining the target hash value with the smallest sort number among the target hash values ​​that have not been hashed in the order of sorting number from smallest to largest, until each target hash value has completed the hash calculation and the first hash calculation result is obtained.

[0031] The second acquisition subunit is used to acquire the historical hash value of the processed historical priority task when the first hash calculation result is the first Merkle root.

[0032] In some embodiments, the second acquisition subunit is configured to:

[0033] Obtain the first block corresponding to the first Merkle root;

[0034] Determine a second block, a preset number of blocks, following the first block;

[0035] The priority tasks stored in each block between the first block and the second block are identified as processed historical priority tasks.

[0036] Obtain the historical hash value for each of the aforementioned historical priority tasks.

[0037] In some embodiments, the second acquisition subunit is configured to:

[0038] Obtain the storage hash value sent by any computer device, wherein the storage hash value is the hash value sent when the historical priority task is put on the chain;

[0039] The stored hash value is determined as the historical hash value of the historical priority task.

[0040] In some embodiments, the second acquisition unit is configured to:

[0041] The first reward return request is marked so that it carries a target marker, so that the first client can respond with the first priority task based on the target marker carried in the first reward return request;

[0042] Receive the first priority task sent by the first client, the first priority task carrying the corresponding first reward;

[0043] Obtain the first reward from the first priority task.

[0044] In some embodiments, the return unit is configured to:

[0045] From the multiple frozen total rewards, determine the first total reward corresponding to the first Merkel root;

[0046] Unfreeze the first reward in the first total reward and return the first reward to the first client.

[0047] In some embodiments, the apparatus further includes:

[0048] The third receiving unit is used to receive a second total reward freeze request sent by the second computer device. The second total reward freeze request includes a second Merkle root, a third block corresponding to the second Merkle root, and a second total reward. The second Merkle root is the Merkle root of the second Merkle tree generated according to the second hash value of the second priority task.

[0049] The freezing unit is used to establish the mapping relationship between the second Merkel tree root and the second total reward, and to freeze the second total reward;

[0050] The second determining unit is used to determine a fourth block, a preset number of blocks, following the third block;

[0051] The unfreezing unit is used to unfreeze the second reward corresponding to the second priority task in the second total reward when the second priority task is in a block between the third processing block and the fourth block;

[0052] The return unit is used to put the second priority task on the blockchain and return the second reward to the second computer device.

[0053] A task processing device, comprising:

[0054] The second receiving unit is used to receive the third priority task sent by the third client, store the third priority task in the priority task pool, and the third priority task carries the third reward corresponding to the third priority task.

[0055] The first determining unit is used to determine the sum of rewards corresponding to each of the priority tasks to be processed when the multiple priority tasks to be processed obtained from the priority task pool include the third priority task, so as to obtain the third total reward.

[0056] A generation unit is used to generate a third Merkle tree based on the unprocessed hash value of each of the unprocessed priority tasks.

[0057] The third acquisition unit is used to acquire the third Merkle root of the third Merkle tree and the fifth block corresponding to the third Merkle root;

[0058] A construction unit is used to construct a third total reward freeze request based on the third total reward, the third Merkel root, and the fifth block;

[0059] The first sending unit is configured to send the third total reward freeze request to the third computer device, so as to freeze the third total reward corresponding to the third Merkel root through the third computer device.

[0060] In some embodiments, the generating unit is configured to:

[0061] Perform hash calculations on each pair of the hash values ​​to be processed to obtain the second hash calculation result;

[0062] When the number of the second hash calculation results is not one, the hash value to be processed is updated to the second hash calculation result, and the process returns to the step of performing hash calculation on each pair of the hash values ​​to be processed to obtain the second hash calculation result, until the number of the second hash calculation results is one, and a third Merkle tree is obtained by combining the multiple second hash calculation results obtained in the hash calculation process and the hash value to be processed.

[0063] In some embodiments, the apparatus further includes:

[0064] The third determining unit is used to determine a sixth block, specifying the number of blocks after the fifth block;

[0065] The fourth receiving unit is configured to receive the third reward returned by the third computer device when the third priority task is located in a block between the fifth and sixth blocks.

[0066] In some embodiments, the apparatus further includes:

[0067] The third acquisition unit is used to acquire the third Merkel path of the third priority task corresponding to the third hash value in the third Merkel tree;

[0068] The second sending unit is used to send the third Merkel root and the third Merkel path to the third client.

[0069] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described task processing method.

[0070] A computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to perform the above-described task processing method.

[0071] A computer program product or computer program includes computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to perform the aforementioned task processing method.

[0072] This application embodiment receives a first reward return request submitted by a first computer device; wherein, the first reward return request carries a first hash value of a first priority task, a first Merkle root, and a first Merkle path, the first Merkle root being the Merkle root of a first Merkle tree generated based on the first hash value, and the first Merkle path including proof that the first Merkle root is a first hash set calculated from the first hash value; when the first hash calculation result of the first hash set and the first hash value is the first Merkle root, the historical hash value of the processed historical priority task is obtained; when the historical hash value is different from the first hash value, the first reward corresponding to the first priority task is obtained; and the frozen first reward is returned to a first client, the first client being a client that requested on-chain processing of the first priority task.

[0073] In this way, a first reward return request is received from a first computer device, carrying a first hash value, a first Merkel root, and a first Merkel path. The authenticity of the first priority task is verified by performing a hash calculation on the first hash value and the first hash set included in the first Merkel path, and comparing the consistency between the first hash calculation result and the first Merkel root. The existence of the first hash value is also checked from the historical hash values ​​of processed historical priority tasks to verify whether the first priority task has been prioritized. When the authenticity of the first priority task is true and it has not been prioritized, the first reward of the frozen first priority task is returned to the first client. Compared with the related technology where the blockchain priority channel is completely determined by the corresponding service provider, this application embodiment provides a priority channel submission technology that realizes the return of the priority processing reward borne by the object when the priority task is not prioritized within the time limit, thereby improving the security of priority services and protecting the rights and interests of the object.

[0074] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0075] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0076] Figure 1 This is a flowchart illustrating the task processing method provided in an embodiment of this application.

[0077] Figure 2 This is a schematic diagram of the Merkle tree structure provided in an embodiment of this application.

[0078] Figure 3 This is an interactive schematic diagram of the reward return process provided in an embodiment of this application.

[0079] Figure 4 This is another flowchart illustrating the task processing method provided in an embodiment of this application.

[0080] Figure 5 This is an interactive schematic diagram of the priority task processing procedure provided in the embodiments of this application.

[0081] Figure 6 This is a schematic diagram of the structure of the task processing device provided in the embodiments of this application.

[0082] Figure 7 Another schematic diagram of the task processing device provided in the embodiments of this application.

[0083] Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0084] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0085] It should be noted that while some processes described in the specification, claims, and accompanying drawings contain multiple steps that appear in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any particular order of execution. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0086] In specific embodiments of this application, data concerning the privacy of the recipient, such as reward return requests, is involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the recipient is required, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, when an embodiment of this application needs to obtain a reward return request, separate permission or consent for the reward return request and related data can be obtained through pop-ups or redirection to a confirmation page. Only after obtaining separate permission or consent can the necessary related data for the normal operation of the embodiment of this application be obtained.

[0087] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0088] Smart contracts are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. Smart contracts allow for trusted tasks without a third party; these tasks are traceable and irreversible. While working similarly to traditional contracts, smart contracts are implemented using blockchain technology. They offer the following characteristics and advantages: 1. Automatic execution: Once predetermined conditions are met, smart contracts automatically execute the corresponding operations without human intervention, reducing the possibility of human error and fraud. 2. Decentralization: Typically running on a blockchain, they do not rely on a single centralized institution, improving the trustworthiness and fairness of the contract. 3. Immutability: Their code and execution records are stored on the blockchain, making them difficult to tamper with and ensuring the security and reliability of the contract. 4. High efficiency and low cost: They eliminate the cumbersome processes and intermediaries of traditional contracts, reducing costs and improving execution efficiency.

[0089] For example, smart contracts can automatically trigger payments based on the shipping status of goods. Smart contracts have a wide range of applications, including the Internet of Things, digital rights management, supply chain management, and many other fields, bringing greater efficiency and transparency to various business processes.

[0090] Nodes: A node can be a server or other computer device capable of participating in the operation and maintenance of the blockchain network. The functions of a node include: 1. Propagating and receiving transaction information: Broadcasting newly generated transactions to the network and receiving transactions from other nodes. 2. Verifying transactions and blocks: Ensuring the legality of transactions and the validity of blocks. 3. Participating in the consensus mechanism: Jointly determining the state and direction of the blockchain.

[0091] For example, in an enterprise-level blockchain application, servers in different departments can act as nodes to jointly maintain the consistency and immutability of business data.

[0092] Hash value: Also known as a hash value, it is a fixed-length numerical value obtained by calculating data using a specific hash function. A hash function is a function that maps input data of arbitrary length to a fixed-length output. No matter how long or complex the input data is, the length of the hash value obtained after processing by the hash function is fixed. Hash values ​​have the following important characteristics and uses: 1. Uniqueness: For the same input data, the hash value obtained by the same hash function is always the same. However, different input data are highly likely to produce different hash values. 2. Fast calculation: It can be generated quickly, facilitating data comparison and storage. 3. Data integrity verification: By comparing the hash values ​​of data, it is possible to quickly determine whether the data has been tampered with. If the data has changed in any way, its hash value will usually be completely different. 4. Data indexing and searching: It can be used to quickly locate and retrieve data.

[0093] For example, in file transfer, a hash value can be calculated for the file. The receiver calculates the hash value again upon receiving the file and compares it with the hash value provided by the sender. If they match, it indicates that the file was not corrupted or tampered with during transmission.

[0094] Priority Task Pool: In blockchain, a priority task pool typically refers to a special storage area or mechanism used to process tasks with high priority or special requirements. The main functions of a priority task pool include: 1. Improving processing efficiency: By concentrating important or urgent tasks in a specific pool, the system can prioritize these tasks, thereby accelerating overall task processing speed. 2. Meeting specific needs: For example, high-value tasks requiring rapid confirmation, or tasks related to critical business processes, can be placed in a priority pool. 3. Optimizing resource allocation: It helps to allocate blockchain network resources more rationally, ensuring that important business processes are processed in a timely manner.

[0095] For example, in a blockchain-based supply chain system, urgent order processing requests can enter a priority task pool for rapid updates to inventory and logistics information. In short, a priority task pool is a mechanism for optimizing blockchain task processing workflows and meeting different priority needs.

[0096] Packaging refers to the process of combining transaction data generated within a certain period into a data block. Specifically, when multiple transactions occur, a specific blockchain node or node collects and combines these transactions according to certain rules and algorithms. The main functions of packaging include: 1. Improving efficiency: Processing multiple transactions at once reduces the number of processing steps and time for individual transactions. 2. Ensuring data consistency: Ensuring that transaction data within a block is interconnected and consistent. 3. Participating in the consensus mechanism: Specific blockchain nodes or nodes that successfully package a block receive a reward, which is part of the blockchain consensus mechanism. Packaging is a crucial step in blockchain operation, ensuring the orderly processing of transactions and the continuous growth of the blockchain.

[0097] On-chain recording refers to the process of recording data or information on a blockchain. Once a task is recorded on the chain, it is encrypted and distributed across various nodes of the blockchain, possessing the following characteristics and significance: 1. Immutability: Once data is on the chain, it is very difficult to alter, ensuring the originality and integrity of the data. 2. Traceability: The generation and modification history of data can be clearly viewed, facilitating traceability and auditing. 3. Decentralized storage: Data is not stored on a single centralized server but distributed across multiple nodes, reducing the risk of single points of failure and data loss. 4. Increased trust: Due to the characteristics of blockchain, on-chain data is more likely to gain the trust of all parties.

[0098] For example, in the supply chain field, putting information about the production, transportation, and sales of goods on the blockchain can make the entire supply chain process more transparent and trustworthy. In short, putting data on the blockchain means incorporating data into the blockchain system to achieve secure storage, reliable sharing, and efficient utilization of data.

[0099] Merkle Tree: A data structure and hash algorithm application. Merkle trees are primarily used to efficiently verify data integrity and consistency. It is a binary tree composed of a series of nodes; leaf nodes typically store the hash value of a data block, while non-leaf nodes store the combined hash value of their two child nodes.

[0100] Merkle path: In a Merkle tree structure, it is the sequence of hash values ​​of the nodes traversed from a leaf node to the root node.

[0101] In related technologies, to expedite the on-chain processing of tasks, objects typically pay priority processing rewards to priority processing services such as task acceleration services and block builder services. However, if the priority processing service fails to package and upload the object's task to the blockchain within the specified time, the reward paid by the object cannot be refunded, failing to effectively protect the object's rights and resulting in low security.

[0102] To address the aforementioned problems, this application proposes a task processing method. The method receives a first reward return request submitted by a first computer device, carrying a first hash value, a first Merkel root, and a first Merkel path. The method verifies the authenticity of the first priority task by performing hash calculations on the first hash value and the first hash set included in the first Merkel path, and comparing the hash calculation result with the first Merkel root. It also queries the historical hash values ​​of processed historical priority tasks to verify whether the first priority task has been prioritized. If the authenticity of the first priority task is true and it has not been prioritized, the first reward of the frozen first priority task is returned to the first client.

[0103] Thus, when a real priority task is not within a specific block, the previously frozen reward corresponding to that priority task can be returned to the corresponding client. This achieves the effect of promptly returning the reward for priority processing submitted by the object, improving the security of priority services, and protecting the rights and interests of the object. Please refer to the following specific embodiments for the detailed implementation process.

[0104] In this embodiment, the description will be from the perspective of a task processing device, which can be integrated into a computer device that has a storage unit and is equipped with a microprocessor and has computing capabilities.

[0105] Please see Figure 1 , Figure 1 This is a flowchart illustrating a task processing method provided in an embodiment of this application. The task processing method is applied to a computer device with smart contracts deployed to implement the corresponding processing logic of the smart contracts, including:

[0106] In step 201, a first reward return request submitted by the first computer device is received.

[0107] To better illustrate the embodiments of this application, taking a reward return request submission scenario as an example, when the first client initiates a first reward return request for a first priority task, it will send the first reward return request to any first computer device in the blockchain other than the computer device corresponding to the original processing node that originally processed the first priority task. After receiving the first reward return request, the first computer device will upload the first reward return request to the blockchain so that the smart contract can receive the first reward return request submitted by the first computer device in the blockchain.

[0108] The first reward return request is a request to return the first reward. Before returning the corresponding reward to the client, the smart contract needs to perform two verification steps. The first step is task authenticity verification, used to verify the authenticity of the priority task; the second step is non-on-chain authenticity verification, used to verify whether the priority task has not been on-chain within the promised on-chain period. For task authenticity verification, when the original computer device packages priority tasks for on-chain, it collects priority tasks within a certain period from the priority task pool to package multiple priority tasks into the same block, so that multiple priority tasks are on-chain along with the block. In the process of packaging multiple priority tasks into the same block, the original computer device generates a Merkle tree based on the hash value of each priority task, and sends the Merkle tree root and the Merkle path corresponding to each priority task to the client that initiated each priority task, so that the client can construct a reward return request based on the received Merkle tree root and Merkle path when the priority task is not processed first.

[0109] Specifically, the reward return request is structured as follows:

[0110] ChallengeTX=<[PRIOR_TXS_ROOT, PATH, PriorTX.Hash]…>;

[0111] ChallengeTX is the reward return request, PRIOR_TXS_ROOT is the Merkel root tree, PATH is the Merkel path, PriorTX is the priority task, and PriorTX.Hash is the hash value corresponding to the priority task.

[0112] Specifically, the first priority task is the priority task initiated by the first client, the first hash value is the hash value generated by the first client based on the first priority task, the first Merkle root is the Merkle root of the first Merkle tree generated by the original computer device when packaging the first priority task, based on the first hash value and the hash values ​​of other priority tasks packaged together with the first priority task, and the first Merkle path includes proof that the first Merkle root is the first hash set calculated from the first hash value.

[0113] For a better illustration of the embodiments of this application, please refer to the following: Figure 2 As shown, Figure 2 This is a schematic diagram of the Merkle tree structure provided in an embodiment of this application. Priority task 1, priority task 2, priority task 3, and priority task 4 are multiple priority tasks obtained when the computer device packages priority tasks into a block; the hash value corresponding to priority task 1 is hash value (1,1), the hash value corresponding to priority task 2 is hash value (1,2), the hash value corresponding to priority task 3 is hash value (2,1), and the hash value corresponding to priority task 4 is hash value (2,2); by calculating the hash calculation result of hash value (1,1) and hash value (1,2), the hash value 1 of the upper-level node is obtained; by calculating the hash calculation result of hash value (2,1) and hash value (2,2), the hash value 2 of the upper-level node is obtained; by calculating the hash calculation result of hash value 1 and hash value 2, the root node, i.e., the root of the Merkle tree, is obtained. If the first priority task is priority task 3, then the first hash value is hash value (2,1). Since the hash calculation result of hash value (2,1) and hash value (2,2) of priority task 3 is hash value 2, and the hash calculation result of hash value 2 and hash value 1 is the first Merkel root, the first hash set included in the first Merkel path corresponding to priority task 3 is (hash value (2,2), hash value 1). That is, the hash calculation result obtained by hashing hash value (2,2) and the first hash value is then calculated with hash value 1 to obtain the first Merkel root.

[0114] In some implementations, receiving a first reward return request submitted by a first computer device includes:

[0115] Receive a first reward return request forwarded by a first computer device. The first reward return request is a request sent to a third computer device when the first client does not detect that the first priority transaction is in any block between the first block and the second block.

[0116] The first reward return request is a request sent by the first client to the first computer device when the first client does not detect that its initiated first priority task is in any of the blocks between the first and second blocks. After obtaining the right to record the first reward return request, the first computer device will put the first reward return request on the blockchain for the smart contract to obtain. The first and second blocks represent the commitment period for the original computer device to put the first priority task on the blockchain to the first client. That is, the original computer device promises the first client that it will package the first priority task into any of the blocks between the first and second blocks so that the first priority task is put on the blockchain with the blocks. For example, there can be an interval of K blocks between the first and second blocks, where K can be 3, 4, or 5, etc.

[0117] Specifically, since the failure to upload the object's priority task to the blockchain might be due to the original computer device being offline or having no incentive to process tasks detrimental to itself, when a client detects that its corresponding priority task has not been uploaded to the blockchain within the promised deadline, its reward return request will not be sent to the original computer device. Instead, it will be sent to another computer device on the same blockchain as the original computer device. This other computer device will then upload the reward return request to the blockchain, allowing the smart contract to verify the uploaded reward return request and return the reward. Therefore, the first computer device is any other computer device on the same blockchain as the computer device that originally processed the first priority task.

[0118] Specifically, the submission process for the reward return request submitted by the first computer device is as follows:

[0119]

[0120] Client refers to the client application, NodeB.Pool refers to the first computer device corresponding to node B, and NodeC.Pool refers to the first computer device corresponding to node C. The reward return request sent by the client is broadcast to the transaction pools of nodes B and C, where it awaits packaging. When nodes B and C obtain the right to record transactions, they upload the reward return request to the blockchain for the smart contract to receive.

[0121] In step 202, when the first hash calculation result of the first hash set and the first hash value is the first Merkle root, the historical hash value of the processed historical priority task is obtained.

[0122] If the first priority task truly exists, the original computer device processing the first priority task will generate a first Merkle tree based on the first hash value of the first priority task, thus obtaining the first Merkle tree root and the first hash set included in the first Merkle path. Based on this, when the smart contract receives the first reward return request, it can perform a hash calculation on the first hash set carried in the first reward return request and the first hash value to determine whether the first hash calculation result of the first hash set and the first hash value is the first Merkle tree root, thereby verifying the authenticity of the first priority task.

[0123] Specifically, if the first hash calculation result of the first hash set and the first hash value is the first Merkle root, it means that the task authenticity of the first priority task corresponding to the first hash value is true, and a computer device has previously packaged the first priority task. If the first hash calculation result of the first hash set and the first hash value is the first Merkle root, it means that the task authenticity of the first priority task corresponding to the first hash value is false, and a computer device has not previously packaged the first priority task.

[0124] In some implementations, when the first hash calculation result of the first hash set and the first hash value is the first Merkle root, the historical hash value of the processed historical priority task is obtained, including:

[0125] (1) Obtain the sorting number of each target hash value in the first hash set;

[0126] (2) According to the sorting number from small to large, the target hash value with the smallest sorting number among the target hash values ​​that have not been hashed is determined as the hash value to be calculated;

[0127] (3) Determine the first hash calculation result of the first hash value and the hash value to be calculated;

[0128] (4) When there is a target hash value that has not been hashed, update the first hash value to the first hash calculation result, and return to execute the step of determining the target hash value with the smallest sorting number among the target hash values ​​that have not been hashed in ascending order of sorting number as the hash value to be calculated, until each target hash value has completed hash calculation and the first hash calculation result is obtained.

[0129] (5) When the first hash calculation result is the first Merkle root, obtain the historical hash value of the processed historical priority task.

[0130] Since the computer device calculates the Merkle tree root by layering the hash values ​​of multiple priority tasks when packaging them, it is also necessary to control the target hash values ​​in the first hash set to be hashed sequentially when verifying the authenticity of the first priority task. Based on this, the sorting sequence number of each target hash value in the first hash set is obtained. This sorting sequence number is the number assigned to each target hash value by the original computer device when generating the Merkle tree layer by layer during the packaging of multiple priority tasks, including the first priority task.

[0131] For example, Figure 2 In the process, the first priority task is priority task 3, and the first set of hash values ​​for the Merkel path of priority task 3 is hash value (2,2); hash value 1. When generating the Merkel tree, the hash value (2,1) corresponding to priority task 3 is first hashed with hash value (2,2) to obtain hash value 2. Then, the hash calculation result of hash value 2 and hash value 1 is calculated to obtain the root of the Merkel tree. Therefore, the sorting number corresponding to hash value (2,2) is 1; the sorting number corresponding to hash value 1 is 2.

[0132] Specifically, when a smart contract verifies the authenticity of a first-priority task, it also performs a layer-by-layer calculation process. First, it determines the target hash value with the smallest sorting number among the target hash values ​​that have not yet undergone hash calculation, in ascending order of sorting number, as the first-level hash value to be calculated. Then, it performs a hash calculation between the target hash value to be calculated and the first hash value. The result of this first hash calculation is the hash calculation result for the first layer. After the first layer calculation is complete, if there are target hash values ​​that have not yet undergone hash calculation, the next layer of hash calculation needs to be performed. At this point, the first hash calculation result needs to be assigned to the first hash value, and the process continues for the remaining target hash values. The target hash value with the smallest sorting index among the target hash values ​​in the row hash calculation is determined as the hash value to be calculated in the second layer. The hash calculation result of the hash value to be calculated and the first hash value after reassignment is calculated again. The hash calculation process of each layer is executed in a loop until the hash calculation of each target hash value is completed, indicating that the hash calculation process of each layer is completed. Then the first hash calculation result is compared with the first Merkle root. If the first hash calculation result is the first Merkle root, it means that the authenticity verification of the first priority task has passed. The first priority task has been packaged by the node before, so the second step of non-chain authenticity verification is performed.

[0133] Therefore, by employing a layer-by-layer calculation approach, starting with the target hash value with the smallest sorting sequence number and progressively performing hash calculations, the orderliness and systematic nature of the computation are ensured. Each layer's calculation is based on the result of the previous layer, making the entire verification process coherent and accurately reflecting the task's authenticity. This progressive calculation method can promptly detect errors in the computation process, improving the accuracy of the verification results. Throughout the hash calculation process, every target hash value participates in the calculation, and the calculation results are interconnected. If any step is tampered with, it will be detected in subsequent calculations, effectively preventing the risk of malicious tampering of task data. Simultaneously, comparing the final hash calculation result with the first Merkle root tree further strengthens the verification of the task's authenticity, ensuring that priority tasks were indeed packaged by nodes beforehand, thus improving data credibility.

[0134] Among them, the non-on-chain authenticity verification refers to verifying whether the first priority task has not been on the chain. The specific verification method is to verify whether the first priority task has a corresponding first hash value among the historical priority tasks that have been processed and on the chain. Therefore, the historical hash value of the processed historical priority task is obtained.

[0135] Specifically, regarding whether a smart contract can read blocks already on the blockchain, there are two ways to obtain the historical hash value of historical priority tasks. The first way is for the smart contract to obtain the historical hash value by reading blocks already on the blockchain. The second way is for the smart contract to determine the hash value stored locally as the historical hash value.

[0136] In some implementations, for the first method of obtaining historical hash values, obtaining the historical hash values ​​of processed historical priority tasks includes:

[0137] (5.1) Obtain the first block corresponding to the first Merkel tree root;

[0138] (5.2) Determine a second block of a preset number of blocks following the first block;

[0139] (5.3) The priority tasks stored in each block between the first block and the second block are determined as processed historical priority tasks;

[0140] (5.4) Obtain the historical hash value for each of the historical priority tasks.

[0141] Specifically, regarding smart contracts being able to read blocks already on the blockchain, during the packaging of priority tasks by processing nodes, the Merkle root of the Merkle tree generated from the hash values ​​of multiple priority tasks, along with the block to which multiple priority tasks are packaged, is uploaded to the blockchain. This allows subsequent smart contracts to retrieve the earliest committed block of the priority tasks included in the Merkle root from the blockchain. Furthermore, regarding the commitment period for on-chain storage, a latest committed block is specified, which is a preset number of blocks following the earliest committed block.

[0142] For example, if the preset number of blocks is K, and the earliest committed block to be added to the chain is N, then the latest committed block to be added to the chain is N+K.

[0143] Specifically, after obtaining the earliest committed block (first block) corresponding to the first Merkle root, the latest committed block (second block) can be determined based on the preset number of blocks. If the first priority task is packaged and added to the chain normally, the first priority task will definitely be in any block between the first block and the second block. Therefore, by determining the priority tasks stored in each block between the first block and the second block as processed historical priority tasks, it can be used to compare whether the hash value corresponding to the historical priority task is different from the first hash value, so as to verify whether the first priority task is in any block between the first block and the second block.

[0144] Therefore, for smart contracts capable of reading already-on-chain blocks, the search range for the first priority task is fixed by obtaining the earliest committed block (the first block) corresponding to the first Merkle root and determining the latest committed block (the second block). Searching within this specific block range avoids time-consuming and computationally intensive global searches, significantly improving search efficiency and reducing system resource consumption and time costs. This allows the system to accurately determine the on-chain status of the first priority task, ensuring its traceability and enhancing system transparency and reliability. Furthermore, by comparing the hash values ​​of historical priority tasks with the first hash value, it's possible to further verify whether the first priority task is within the specific block range. If the hash values ​​differ, it can be quickly determined that the priority task is not within the range; otherwise, it is. This provides strong evidence for the authenticity of priority tasks not being on-chain, preventing them from being incorrectly identified or missed.

[0145] In some implementations, for the second method of obtaining historical hash values, obtaining the historical hash values ​​of processed historical priority tasks includes:

[0146] (5.1) Obtain the storage hash value sent by any computer device, wherein the storage hash value is the hash value sent when the historical priority task is put on the chain;

[0147] (5.2) The stored hash value is determined as the historical hash value of the historical priority task.

[0148] Specifically, for cases where smart contracts cannot read blocks that have already been uploaded to the blockchain, after successfully packaging and uploading priority tasks to the blockchain, the processing node will send the hash value corresponding to the priority task to the smart contract so that the smart contract can store the hash value of each priority task.

[0149] Specifically, when verifying whether the first priority task has been uploaded to the blockchain, the smart contract only needs to determine the stored multiple hash values ​​as the historical hash values ​​of the historical priority tasks, and use them to compare whether the hash values ​​corresponding to the historical priority tasks are different from the first hash value, so as to verify whether the first priority task has been uploaded to the blockchain.

[0150] Therefore, to address the issue of smart contracts being unable to read blocks already on the blockchain, storing the hash value of each priority task eliminates the need for smart contracts to search and retrieve priority task hash values ​​from the entire blockchain again. Instead, they only need to compare the stored hash values, reducing data search time and computational resource consumption, and improving verification efficiency. During verification, the smart contract can precisely compare the hash values ​​of historical priority tasks with the first hash value to determine if they differ. The uniqueness of the hash value ensures accurate determination of whether the first priority task is on the blockchain, even among a large amount of task data. This enhances the accuracy and reliability of verification and reduces the risk of misjudgment.

[0151] In step 203, when the historical hash value is different from the first hash value, the first reward corresponding to the first priority task is obtained.

[0152] The first reward is the reward that the first client pays to the original processing node for prioritizing the first priority task when the first client applies for priority processing of the first priority task. Unlike related technologies, this application pre-freezes the reward that the client pays to the processing node for applying for priority processing of the priority task, so that the client can obtain the corresponding reward from the frozen reward when the processing node prioritizes the priority task; or, if the processing node does not prioritize the priority task, the smart contract can return the corresponding reward from the frozen reward to the client.

[0153] Therefore, if the historical hash value is different from the first hash value, it means that the first priority task has not been put on the chain. Since the first priority task really exists, it is necessary to obtain the first reward corresponding to the first priority task, so that the first reward for prioritizing the processing of the first priority task can be returned to the first client.

[0154] Specifically, for smart contracts that can read blocks already on the blockchain, the verification process for unverified blocks is as follows:

[0155]

[0156] Where Res2 represents the verification result, 0 for false and 1 for true, and Block... i .TXs represents the hash values ​​of the priority tasks included in block i. The result of taking the union of each block from N to N+K is TX. j .Hash, also known as historical hash value. If the hash value PriorTX.Hash of the first priority transaction matches the historical hash value TX... j If the hash value PriorTX.Hash is different from the historical hash value TX, then Res2 is 1; j If the .Hash values ​​are the same, then Res2 is 0.

[0157] Specifically, for smart contracts that cannot read blocks already on the blockchain, the verification process for unverified blockchain authenticity takes the following form:

[0158] Res2=PriorContract.NotExsits(PriorTX.Hash);

[0159] Among them, PriorContract is the priority contract in the smart contract used to handle priority task-related functions, and NotExsits(PriorTX.Hash) is a function that stores the hash value of a priority task in the contract and does not contain the hash of a certain priority task.

[0160] In some implementations, obtaining the first reward corresponding to the first priority task includes:

[0161] (1) Identify the first reward return request so that the first reward return request carries a target marker, so that the first client can return the first priority task based on the first reward return request carrying the target marker;

[0162] (2) Receive the first priority task sent by the first client, wherein the first priority task carries the corresponding first reward;

[0163] (3) Obtain the first reward from the first priority task.

[0164] Specifically, when the smart contract passes both the verification of the authenticity of the first priority task and the verification of its non-on-chain authenticity, it will mark the first reward return request in the blockchain, causing the first reward return request to carry a target marker. Thus, when the first client finds that the first reward return request in the blockchain carries the target marker, it proactively sends the original text of the first priority task to the smart contract. The original text carries the request for priority processing of the first reward for the first priority task, so that the smart contract can obtain the first reward from the received first priority task.

[0165] Therefore, after successful verification, the first reward return request is marked, carrying a target marker. When the first client queries the first reward return request with the target marker, it will proactively send the plaintext of the first priority task to the smart contract. This automatically triggered mechanism reduces the need for manual intervention and improves the automation level of the process.

[0166] In some implementations, the first reward return request also carries a first reward, and obtaining the first reward corresponding to the first priority task includes:

[0167] Retrieve the first reward from the first reward return request.

[0168] To expedite the return of rewards, the first client can include the first reward in the first reward return request when initiating it. This allows the smart contract to directly retrieve the first reward from the first reward return request once both the task authenticity verification and the off-chain authenticity verification for the first priority task have passed.

[0169] In step 204, the frozen first reward is returned to the first client, which is the client that requested the on-chain processing of the first priority task.

[0170] When a processing node receives a priority task, it freezes the corresponding reward in a smart contract. When the priority task is uploaded to the blockchain within the promised deadline, the node will receive the frozen reward from the smart contract. If the priority task is not uploaded to the blockchain within the promised deadline, the smart contract will return the frozen reward to the corresponding client when both the authenticity verification of the priority task and the authenticity verification of not being uploaded to the blockchain are passed.

[0171] Based on this, after the smart contract receives the first reward, it will return the first reward frozen in the smart contract to the first client.

[0172] In some implementations, returning the frozen first reward to the first client includes:

[0173] (1) Determine the first total reward corresponding to the first Merkel root from the multiple frozen total rewards;

[0174] (2) Unfreeze the first reward in the first total reward and return the first reward to the first client.

[0175] Since the processing node packages multiple priority tasks into the same block, the rewards corresponding to multiple priority tasks in the same block will be sent to the smart contract as a total reward for freezing. Therefore, when the smart contract returns the reward of a certain priority task, it needs to find the corresponding total reward according to the Merkle root, unfreeze the reward of the priority task from the frozen corresponding total reward, and return it.

[0176] Specifically, according to the smart contract, the first total reward corresponding to the first Merkle root will be found based on the mapping relationship between the Merkle root and the total reward, and the first reward in the first total reward will be unfrozen to return the first reward to the first client.

[0177] In this way, by mapping the Merkle root to the total reward, smart contracts can accurately find the total reward corresponding to a specific task. This ensures the accuracy of reward returns and avoids mistakenly returning rewards to the wrong client.

[0178] In some implementations, the method further includes:

[0179] (1) Receive a second total reward freeze request sent by a second computer device. The second total reward freeze request includes a second Merkle root, a third block corresponding to the second Merkle root, and a second total reward. The second Merkle root is the Merkle root of the second Merkle tree generated according to the second hash value of the second priority task.

[0180] (2) Establish the mapping relationship between the second Merkel tree root and the second total reward, and freeze the second total reward;

[0181] (3) Determine the fourth block, which is a preset number of blocks after the third block;

[0182] (4) When the second priority task is located in a block between the third processing block and the fourth block, unfreeze the second reward corresponding to the second priority task in the second total reward;

[0183] (5) Put the second priority task on the blockchain and return the second reward to the second computer device.

[0184] If the smart contract receives a second total reward freeze request sent by the second computer device, it means that the second computer device has packaged multiple priority tasks and sent the second Merkle root of the second Merkle tree generated by the hash values ​​of the multiple priority tasks and the second total reward of the multiple priority tasks to the smart contract in the form of a second total reward freeze request.

[0185] Specifically, when the smart contract receives the second Merkle root and the second total reward, it establishes a mapping relationship between the second Merkle root and the second total reward, and freezes the second total reward so that when the second computer device adds a block of a priority task, it can request the corresponding reward from the frozen second total reward. Also, when the second computer device adds a block of a priority task, it can find the second total reward based on the second Merkle root, unfreeze a certain reward from the frozen second total reward, and return it.

[0186] In order for the smart contract to proactively return the frozen reward of the priority task to the processing node's computer device when the priority task is put on the chain within the promised on-chain period, the processing node needs to include the block of the priority task packaged in the second total reward freeze request. This allows the smart contract to know the earliest promised on-chain block of the priority task and, in combination with the preset number of blocks, know the latest promised on-chain block.

[0187] Specifically, if a priority task is put on the blockchain within its corresponding commitment period (within the block between the earliest and latest committed blockchain blocks), it means that the processing node has kept its commitment to put the priority task on the blockchain. Therefore, the reward corresponding to the priority task in the total reward is unfrozen, the priority task is put on the blockchain, and the reward is returned to the computer device corresponding to the processing node.

[0188] Based on this, the smart contract obtains the earliest committed blockchain block (third block) from the second total reward freeze request. If it detects that the second priority task is located in the block between the earliest committed blockchain block (third block) and the latest committed blockchain block (fourth block), it unfreezes the second reward corresponding to the second priority task in the second total reward; puts the second priority task on the blockchain, and returns the second reward to the second computer device.

[0189] Specifically, priority tasks include the virtual resources and rewards that the task originally needed to be put on the blockchain. Therefore, the original virtual resources of the task need to be put on the blockchain, and the rewards need to be returned to the computer device corresponding to the processing node.

[0190] Therefore, upon receiving a request to freeze the total reward, the smart contract freezes the total reward to prevent its misuse or misallocation, ensuring reward security. Rewards are only unfrozen and returned when a specific priority task is added to the blockchain within the promised deadline, ensuring reward security and accuracy. Furthermore, by establishing a mapping between the Merkle root and the total reward, the corresponding total reward can be accurately located based on the Merkle root, thus accurately unfreezing and returning rewards for specific priority tasks, avoiding erroneous operations.

[0191] In some implementations, please refer to Figure 3 , Figure 3This is an interactive diagram illustrating the reward return process provided in this application embodiment. When the client detects that there is no priority task it initiated in blocks N to N+K, it sends a reward return request to node B. The reward return request is broadcast by nodes B and C, reaching the task pools of nodes B and C to await packaging. In block N+K+1 or later, nodes B and C acquire the right to record transactions and package the reward return request onto the blockchain. When the smart contract detects that node B and / or node C have packaged and submitted the reward return request onto the blockchain, it performs two verification processes: task authenticity verification and non-on-chain authenticity verification. When the verification passes, the reward for the priority task initiated by the frozen client is returned.

[0192] As described above, this application embodiment receives a first reward return request submitted by a first computer device; wherein, the first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task, the first Merkle root being the Merkle root of a first Merkle tree generated based on the first hash value, and the first Merkle path including proof that the first Merkle root is a first hash set calculated from the first hash value; when the first hash calculation result of the first hash set and the first hash value is the first Merkle root, the historical hash value of the processed historical priority task is obtained; when the historical hash value is different from the first hash value, the first reward corresponding to the first priority task is obtained; and the frozen first reward is returned to a first client, the first client being a client that requested on-chain processing of the first priority task.

[0193] In this way, a first reward return request is received from a first computer device, carrying a first hash value, a first Merkel root, and a first Merkel path. The authenticity of the first priority task is verified by performing a hash calculation on the first hash value and the first hash set included in the first Merkel path, and comparing the consistency between the first hash calculation result and the first Merkel root. The existence of the first hash value is also checked from the historical hash values ​​of processed historical priority tasks to verify whether the first priority task has been prioritized. When the authenticity of the first priority task is true and it has not been prioritized, the first reward of the frozen first priority task is returned to the first client. Compared with the related technology where the blockchain priority channel is completely determined by the corresponding service provider, this application embodiment provides a priority channel submission technology that realizes the return of the priority processing reward borne by the object when the priority task is not prioritized within the time limit, thereby improving the security of priority services and protecting the rights and interests of the object.

[0194] Please see Figure 4 , Figure 4Another flowchart illustrating the task processing method provided in this application embodiment. This task processing method is applied to a computer device with deployed processing nodes to implement the corresponding processing logic of the processing nodes, including:

[0195] In step 301, the third priority task sent by the third client is received and stored in the priority task pool.

[0196] Among them, the third priority task carries the third reward for requesting priority processing of the third priority task. Since the processing node needs to package a large number of priority tasks and put them on the chain, when it receives a priority task, it will store the priority task in the priority task pool and wait for subsequent packaging.

[0197] Specifically, priority tasks can take the following form:

[0198] PriorTX=[TargetTX,TransferTX];

[0199] Among them, PriorTX is the priority task, TargetTX is the original task, and TransferTX is the reward task that is prioritized for the original task.

[0200] Specifically, the original task can take the following form:

[0201] TargetTX =<User,Receipt,Value,Data> ;

[0202] In this context, User represents the initiator (client), Receipt represents the receiver (the object or smart contract being received), Value represents the virtual resource, and Data represents the input (if any) to the smart contract. The meanings of these fields are common in traditional blockchain technology and will not be explained in detail.

[0203] Specifically, reward tasks can take the following forms:

[0204] TransferTX =<User,AddrA,FeeA,—> ;

[0205] Where AddrA is the address of processing node A, and FeeA is the reward sent to processing node A. It can be understood that processing node A is used as the processing node to process the priority task. If processing node B is used as the processing node to process the priority task, then AddrA in the reward task needs to be replaced with AddrB, and FeeA needs to be replaced with FeeB.

[0206] In step 302, when multiple pending priority tasks obtained from the priority task pool include a third priority task, the sum of the rewards corresponding to each pending priority task is determined to obtain the third total reward.

[0207] Since the processing node packages multiple priority tasks into a certain block, the packaging process for the third priority task also involves the processing node obtaining multiple pending priority tasks, including the third priority task, from the priority task pool to package the multiple pending priority tasks.

[0208] Specifically, in order to regulate the specific blockchain nodes or blockchain builders that act as processing nodes and prevent processing nodes from directly obtaining rewards when priority tasks are not on the chain, processing nodes need to calculate the sum of the rewards corresponding to each priority task to be processed in the package when packaging multiple priority tasks to obtain the third total reward.

[0209] For example, if a processing node packages priority task 1, priority task 2, and priority task 3 into the same block, and the reward for priority task 1 is reward A, the reward for priority task 2 is reward B, and the reward for priority task 3 is reward C, then the total reward is reward A + reward B + reward C.

[0210] Specifically, multiple pending priority tasks obtained from the priority task pool can take the following form:

[0211] PriorTXs=NodeA.GetFrom(PriorPool);

[0212] Here, PriorTXs represents multiple pending priority tasks, PriorPool is the priority task pool, and NodeA is the processing node A. That is, multiple pending priority tasks are obtained from the priority task pool of processing node A. It can be understood that node A is used as the processing node for these priority tasks. If node B were used as the processing node for priority tasks, then NodeA would simply be replaced with NodeB.

[0213] Specifically, the process of determining the total reward can take the following form:

[0214] Sum+ = PriorTX i .TransferTX.Value(PriorTX i ∈PriorTXs);

[0215] Among them, PriorTX i For any of the multiple pending priority tasks PriorTXs, PriorTX i .TransferTX.Value is PriorTX iThe corresponding reward, Sum+, is the total reward obtained by summing the rewards for each priority task.

[0216] In step 303, a third Merkle tree is generated based on the hash value of each priority task to be processed.

[0217] In order for subsequent clients and smart contracts to mark a certain priority task, a third Merkle tree needs to be generated based on the pending hash value of each priority task. The Merkle tree represents the multiple priority tasks included in a block.

[0218] In some implementations, a third Merkle tree is generated based on the unprocessed hash value of each of the aforementioned priority tasks, including:

[0219] (1) Perform hash calculation on each pair of the hash values ​​to be processed to obtain the second hash calculation result;

[0220] (2) When the number of the second hash calculation results is not one, update the hash value to be processed to the second hash calculation result, and return to the step of performing hash calculation on each pair of the hash values ​​to be processed to obtain the second hash calculation result, until the number of the second hash calculation results is one, and obtain the third Merkle tree composed of multiple second hash calculation results obtained in the hash calculation process and the hash value to be processed.

[0221] In the process of generating the third Merkle tree by the processing node based on the unprocessed hash values ​​of multiple unprocessed priority tasks, a hash calculation is performed on each pair of unprocessed hash values ​​in a bottom-up hash calculation to finally obtain a unique hash calculation result, thereby forming the Merkle tree.

[0222] For details, please refer to Figure 2It includes pending priority task 1, pending priority task 2, pending priority task 3, and pending priority task 4. The pending hash value of pending priority task 1 is hash value (1,1), the pending hash value of pending priority task 2 is hash value (1,2), the pending hash value of pending priority task 3 is hash value (2,1), and the pending hash value of pending priority task 4 is hash value (2,2). Following the method of performing hash calculations on each pair of hash values ​​to be processed, the second hash calculation result of hash value (1,1) and hash value (1,2) is hash value 1, and the second hash calculation result of hash value (2,1) and hash value (2,2) is hash value 2. Since there are two second hash calculation results, the value of the second hash calculation result is assigned to the hash value to be processed, and the process of performing hash calculations on each pair of hash values ​​to be processed to obtain the second hash calculation result continues. That is, the second hash calculation result of hash value 1 and hash value 1 is calculated. At this time, since there is only one second hash calculation result obtained from the recalculation, which is the Merkle root, the calculation ends, and a Merkle tree is formed.

[0223] Therefore, by performing bottom-up hash calculations on each pair of hash values ​​to be processed, a unique hash result is obtained, forming a Merkle tree, which can effectively detect data integrity. If the data for a priority task is tampered with, different results will be generated during the hash calculation process, thus enabling timely detection of data anomalies and ensuring data accuracy and integrity. Furthermore, the Merkle tree structure allows for verification of a specific priority task without needing to calculate and verify the entire dataset; only the hash values ​​on the specific paths related to that priority task need to be calculated and compared. This improves the efficiency of data verification and reduces the consumption of computing resources and time costs.

[0224] In step 304, the third Merkle root of the third Merkle tree and the fifth block corresponding to the third Merkle root are obtained.

[0225] After generating the third Merkle tree, the third Merkle tree root is obtained, which is the second hash calculation result that is the only one calculated when the Merkle tree is generated. Furthermore, to allow subsequent clients and smart contracts to know the block containing the third priority task, the fifth block containing multiple pending priority tasks including the third priority task is simultaneously obtained; this is the fifth block corresponding to the third Merkle tree root.

[0226] Specifically, the process of obtaining the Merkel tree roots for obtaining the Merkel tree can take the following form:

[0227] PRIOR_TXS_ROOT=MerkleTree(PriorTXs).Root;

[0228] Where PRIOR_TXS_ROOT is the Merkle tree root, MerkleTree is the function that constructs the Merkle tree, and Root is the root of the constructed Merkle tree.

[0229] Specifically, unlike other technologies where the approximate on-chain time of priority tasks cannot be known after sending them to the computer device of the processing node, this application embodiment provides that during the packaging process of priority tasks by the processing node, the Merkle root of the Merkle tree generated from the hash values ​​of multiple priority tasks and the block to which the multiple priority tasks are packaged are returned to the client. This allows the client and smart contract to obtain the corresponding block based on the Merkle root, and thus know the earliest on-chain time promised by the original computer device corresponding to the processing node for multiple priority tasks, that is, the earliest time that these priority tasks will be packaged into a certain block for on-chain.

[0230] In step 305, a third total reward freeze request is constructed based on the third total reward, the third Merkel root, and the fifth block.

[0231] Specifically, the third total reward, the third Merkel root, and the fifth block are constructed into a third total reward freeze request, which is used to request the freezing of the third total reward.

[0232] In some implementations, after obtaining the third Merkle root of the third Merkle tree and the fifth block corresponding to the third Merkle root, the method further includes:

[0233] (1) Determine the sixth block, which is the specified number of blocks following the fifth block;

[0234] (2) When the third priority task is located in a block between the fifth block and the sixth block, the third reward is received from the third computer device.

[0235] Because of the commitment deadline for on-chain processing, when a processing node starts packaging multiple pending priority tasks, the fifth block to which it is prepared for packaging is the earliest committed block. The processing node will then determine the sixth block as the latest committed block based on the fifth block and the specified number of blocks.

[0236] Specifically, when a processing node detects that the third priority task is located in a block between the fifth and sixth blocks, it indicates that the third priority task has complied with the promised on-chain deadline and has been uploaded to the blockchain. In this case, the node receives the third reward returned by the third computer device used as a smart contract.

[0237] Specifically, for smart contracts that cannot read blocks already on the chain, processing nodes need to use smart contracts to collect rewards and store the hash value of the current priority task in the smart contract (by writing a function in the smart contract that uses the smart contract's reserved word for the hash value). This allows them to indicate to the contract that they have successfully packaged the priority task onto the chain while receiving the reward.

[0238] In this way, by committing to on-chain deadlines and establishing a reward mechanism, it is ensured that different processing nodes operate under fair rules. Processing nodes that comply with the rules receive rewards, while those that violate the rules do not, which helps maintain the fairness of the system and promotes healthy competition.

[0239] In step 306, a third total reward freeze request is sent to the third computer device to freeze the third total reward corresponding to the third Merkel root through the third computer device.

[0240] The third computer device is a computer device used as a smart contract. The processing node sends a third total reward freeze request to the third computer device so that the third computer device freezes the third total reward corresponding to the third Merkle root. That is, the third computer device freezes the third total reward of multiple pending priority tasks represented by the third Merkle root.

[0241] In some implementations, after sending the third total reward freeze request to the third computer device, the method further includes:

[0242] (1) Obtain the third Merkle path of the third priority task corresponding to the third hash value in the third Merkle tree;

[0243] (2) Send the third Merkel root and the third Merkel path to the third client.

[0244] In order for the third client that initiates the third priority task to construct a third reward return request when the third priority task is not on the chain within the promised on-chain period, it is necessary to obtain the third Merkle path of the third priority task corresponding to the third hash value in the third Merkle tree, and send the third Merkle tree root and the third Merkle path to the third client so that the third client can subsequently construct the third reward return request based on the third Merkle tree root and the third Merkle path.

[0245] Specifically, the method for obtaining Merkel's path can be as follows:

[0246] PATH=MerkleTree(PriorTXs).PathOf(PriorTX);

[0247] MerkleTree(PriorTXs) is a Merkle tree constructed from the hash values ​​of multiple priority tasks, and PathOf is a function that retrieves the Merkle path proof corresponding to a specific priority task (PriorTX) from the Merkle tree.

[0248] Specifically, when obtaining the Merkel path, it is also necessary to mark each hash value in the set of hash values ​​included in the Merkel path with an index. The marking method is to determine the level of each hash value in the Merkel tree, mark each hash value in order from bottom to top, and obtain the sort index of each hash value.

[0249] For example, Figure 2 In the first Merkel path corresponding to priority task 3, the first hash set is (hash value (2,2), hash value 1). Since hash value (2,2) is the first level in the first Merkel tree and hash value 1 is the second level in the first Merkel tree, the sorting number of hash value (2,2) is 1 and the sorting number of hash value 1 is 2.

[0250] In this way, by sending the third Merkle root and path to the third client, the third client can construct a request to claim the return of the third reward if the third priority task is not on-chain within the promised deadline, thus protecting the client's rights. If the task fails to be on-chain on time, the client will not suffer losses due to unreasonable waiting and can protect its rights by requesting the return of the reward.

[0251] In some implementations, please refer to Figure 5 , Figure 5 This is an interactive diagram illustrating the priority task processing process provided in this application embodiment. When a client needs to request priority processing for an original task, it needs to construct a reward task. The reward task and the original task are then combined to form a priority task, which is then submitted to the processing node A designated by the client. Processing node A generates a Merkle tree based on the hash values ​​of multiple pending priority tasks, including the priority task initiated by the client, and determines the total reward for the multiple pending priority tasks. It then sends a request to freeze the total reward, including the Merkle tree root and the total reward, to the smart contract to freeze the reward. When processing node A uploads a priority task to the blockchain within K blocks from block N to block N+K, processing node A retrieves the frozen reward for that priority task from the smart contract. Furthermore, after generating the Merkle tree, it sends the Merkle tree root and the Merkle path for the priority task specific to the client to the client so that the client can subsequently construct a reward return request.

[0252] As described above, this embodiment of the application receives a third priority task sent by a third client, stores the third priority task in a priority task pool, and the third priority task carries a third reward corresponding to the third priority task; when multiple pending priority tasks obtained from the priority task pool include the third priority task, the sum of the rewards corresponding to each pending priority task is determined to obtain a third total reward; a third Merkle tree is generated based on the pending hash value of each pending priority task; the third Merkle tree root and the fifth block corresponding to the third Merkle tree root are obtained; a third total reward freeze request is constructed based on the third total reward, the third Merkle tree root, and the fifth block; the third total reward freeze request is sent to a third computer device to freeze the third total reward corresponding to the third Merkle tree root through the third computer device.

[0253] Therefore, by generating a third Merkle tree based on the hash values ​​of pending priority tasks, including the third priority task, upon receiving the third priority task, a means of marking priority tasks is provided for subsequent third clients and smart contracts. Obtaining the third Merkle tree root and the corresponding fifth block allows the third client and smart contract to accurately determine the position of the third priority task. This facilitates the third client's understanding of the task's processing progress and status. Freezing rewards through smart contracts reduces the possibility of human error and malicious behavior, enhancing the system's security and stability. Simultaneously, the transparency of smart contracts makes reward management more open and supervised, increasing the overall trustworthiness of the system.

[0254] For details on the implementation of each of the above steps, please refer to the previous examples, which will not be repeated here.

[0255] To facilitate better implementation of the task processing method provided in the embodiments of this application, the embodiments of this application also provide an apparatus based on the above-described task processing method. The meanings of the terms used are the same as in the task processing method described above, and specific implementation details can be found in the descriptions in the method embodiments.

[0256] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application. The task processing device is applied to a computer device. The task processing device may include a first receiving unit 401, a first acquiring unit 402, a second acquiring unit 403, and a return unit 404, etc.

[0257] The first receiving unit 401 is used to receive a first reward return request submitted by the first computer device;

[0258] The first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task. The first Merkle root is the Merkle root of a first Merkle tree generated based on the first hash value. The first Merkle path includes proof that the first Merkle root is a first hash set calculated from the first hash value.

[0259] The first acquisition unit 402 is used to acquire the historical hash value of the processed historical priority task when the first hash calculation result of the first hash set and the first hash value is the first Merkle root.

[0260] The second acquisition unit 403 is used to acquire the first reward corresponding to the first priority task when the historical hash value is different from the first hash value;

[0261] Return unit 404 is used to return the frozen first reward to the first client, which is the client that requested the first priority task to be processed on the blockchain.

[0262] In some embodiments, the first acquisition unit 402 includes:

[0263] The first acquisition subunit is used to acquire the sorting number of each target hash value in the first hash set;

[0264] The first determining subunit is used to determine the target hash value with the smallest sorting number among the target hash values ​​that have not been hashed, according to the sorting number in ascending order, as the hash value to be calculated;

[0265] The second determining subunit is used to determine the first hash calculation result of the first hash value and the hash value to be calculated;

[0266] The first update subunit is used to update the first hash value to the first hash calculation result when there is a target hash value that has not been hashed in the target hash value, and return to execute the step of determining the target hash value with the smallest sort number among the target hash values ​​that have not been hashed in the order of sorting number from smallest to largest, until each target hash value has completed the hash calculation and the first hash calculation result is obtained.

[0267] The second acquisition subunit is used to acquire the historical hash value of the processed historical priority task when the first hash calculation result is the first Merkle root.

[0268] In some embodiments, the second acquisition subunit is configured to:

[0269] Obtain the first block corresponding to the first Merkle root;

[0270] Determine a second block, a preset number of blocks, following the first block;

[0271] The priority tasks stored in each block between the first block and the second block are identified as processed historical priority tasks.

[0272] Obtain the historical hash value for each of the aforementioned historical priority tasks.

[0273] In some embodiments, the second acquisition subunit is configured to:

[0274] Obtain the storage hash value sent by any computer device, wherein the storage hash value is the hash value sent when the historical priority task is put on the chain;

[0275] The stored hash value is determined as the historical hash value of the historical priority task.

[0276] In some embodiments, the second acquisition unit is configured to:

[0277] The first reward return request is marked so that it carries a target marker, so that the first client can respond with the first priority task based on the target marker carried in the first reward return request;

[0278] Receive the first priority task sent by the first client, the first priority task carrying the corresponding first reward;

[0279] Obtain the first reward from the first priority task.

[0280] In some embodiments, the return unit 404 is configured to:

[0281] From the multiple frozen total rewards, determine the first total reward corresponding to the first Merkel root;

[0282] Unfreeze the first reward in the first total reward and return the first reward to the first client.

[0283] In some embodiments, the apparatus further includes:

[0284] The third receiving unit is used to receive a second total reward freeze request sent by the second computer device. The second total reward freeze request includes a second Merkle root, a third block corresponding to the second Merkle root, and a second total reward. The second Merkle root is the Merkle root of the second Merkle tree generated according to the second hash value of the second priority task.

[0285] The freezing unit is used to establish the mapping relationship between the second Merkel tree root and the second total reward, and to freeze the second total reward;

[0286] The second determining unit is used to determine a fourth block, a preset number of blocks, following the third block;

[0287] The unfreezing unit is used to unfreeze the second reward corresponding to the second priority task in the second total reward when the second priority task is in a block between the third processing block and the fourth block;

[0288] The return unit is used to put the second priority task on the blockchain and return the second reward to the second computer device.

[0289] As described above, in this embodiment, the first receiving unit 401 receives a first reward return request submitted by a first computer device. The first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task. The first Merkle root is the Merkle root of a first Merkle tree generated based on the first hash value. The first Merkle path includes proof that the first Merkle root is a first hash set calculated from the first hash value. The first obtaining unit 402 obtains the historical hash value of the processed historical priority task when the first hash calculation result of the first hash set and the first hash value is the first Merkle root. The second obtaining unit 403 obtains the first reward corresponding to the first priority task when the historical hash value is different from the first hash value. The return unit 404 returns the frozen first reward to a first client, which is the client requesting on-chain processing of the first priority task.

[0290] In this way, a first reward return request is received from a first computer device, carrying a first hash value, a first Merkel root, and a first Merkel path. The authenticity of the first priority task is verified by performing a hash calculation on the first hash value and the first hash set included in the first Merkel path, and comparing the consistency between the first hash calculation result and the first Merkel root. The existence of the first hash value is also checked from the historical hash values ​​of processed historical priority tasks to verify whether the first priority task has been prioritized. When the authenticity of the first priority task is true and it has not been prioritized, the first reward of the frozen first priority task is returned to the first client. Compared with the related technology where the blockchain priority channel is completely determined by the corresponding service provider, this application embodiment provides a priority channel submission technology that realizes the return of the priority processing reward borne by the object when the priority task is not prioritized within the time limit, thereby improving the security of priority services and protecting the rights and interests of the object.

[0291] Please see Figure 7 , Figure 7This is another schematic diagram of the task processing device provided in an embodiment of this application, which is applied to a computer device. The task processing device may include a second receiving unit 501, a first determining unit 502, a generating unit 503, a third acquiring unit 504, a constructing unit 505, and a first sending unit 506, etc.

[0292] The second receiving unit 501 is used to receive the third priority task sent by the third client, store the third priority task in the priority task pool, and the third priority task carries the third reward corresponding to the third priority task.

[0293] The first determining unit 502 is used to determine the sum of rewards corresponding to each of the priority tasks to be processed when the multiple priority tasks to be processed obtained from the priority task pool include the third priority task, and to obtain the third total reward.

[0294] The generation unit 503 is used to generate a third Merkle tree based on the unprocessed hash value of each of the unprocessed priority tasks.

[0295] The third acquisition unit 504 is used to acquire the third Merkle root of the third Merkle tree and the fifth block corresponding to the third Merkle root;

[0296] Construction unit 505 is used to construct a third total reward freeze request based on the third total reward, the third Merkel root, and the fifth block;

[0297] The first sending unit 506 is used to send the third total reward freeze request to the third computer device, so as to freeze the third total reward corresponding to the third Merkel root through the third computer device.

[0298] In some embodiments, the generation unit 503 is configured to:

[0299] Perform hash calculations on each pair of the hash values ​​to be processed to obtain the second hash calculation result;

[0300] When the number of the second hash calculation results is not one, the hash value to be processed is updated to the second hash calculation result, and the process returns to the step of performing hash calculation on each pair of the hash values ​​to be processed to obtain the second hash calculation result, until the number of the second hash calculation results is one, and a third Merkle tree is obtained by combining the multiple second hash calculation results obtained in the hash calculation process and the hash value to be processed.

[0301] In some embodiments, the apparatus further includes:

[0302] The third determining unit is used to determine a sixth block, specifying the number of blocks after the fifth block;

[0303] The fourth receiving unit is configured to receive the third reward returned by the third computer device when the third priority task is located in a block between the fifth and sixth blocks.

[0304] In some embodiments, the apparatus further includes:

[0305] The third acquisition unit is used to acquire the third Merkel path of the third priority task corresponding to the third hash value in the third Merkel tree;

[0306] The second sending unit is used to send the third Merkel root and the third Merkel path to the third client.

[0307] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0308] As described above, in this embodiment, the second receiving unit 501 receives the third priority task sent by the third client and stores the third priority task in the priority task pool. The third priority task carries the third reward corresponding to the third priority task. When the first determining unit 502 obtains multiple pending priority tasks from the priority task pool, including the third priority task, it determines the sum of the rewards corresponding to each pending priority task to obtain the third total reward. The generating unit 503 generates a third Merkle tree based on the pending hash value of each pending priority task. The third obtaining unit 504 obtains the third Merkle tree root and the fifth block corresponding to the third Merkle tree root. The constructing unit 505 constructs a third total reward freezing request based on the third total reward, the third Merkle tree root, and the fifth block. The first sending unit 506 sends the third total reward freezing request to the third computer device to freeze the third total reward corresponding to the third Merkle tree root through the third computer device.

[0309] Therefore, by generating a third Merkle tree based on the hash values ​​of pending priority tasks, including the third priority task, upon receiving the third priority task, a means of marking priority tasks is provided for subsequent third clients and smart contracts. Obtaining the third Merkle tree root and the corresponding fifth block allows the third client and smart contract to accurately determine the position of the third priority task. This facilitates the third client's understanding of the task's processing progress and status. Freezing rewards through smart contracts reduces the possibility of human error and malicious behavior, enhancing the system's security and stability. Simultaneously, the transparency of smart contracts makes reward management more open and supervised, increasing the overall trustworthiness of the system.

[0310] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0311] Reference Figure 8 , Figure 8 This is a partial structural block diagram of a computer device 110 implementing an embodiment of the present disclosure. The computer device 110 can vary significantly due to different configurations or performance characteristics, and may include one or more central processing units (CPUs) 622 (e.g., one or more processors) and a memory 632, and one or more storage media 630 (e.g., one or more mass storage devices) storing application programs 642 or data 644. The memory 632 and storage media 630 may be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the computer device 600. Furthermore, the central processing unit 622 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the computer device 600.

[0312] Computer device 110 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0313] When computer device 110 is used as a smart contract, the central processing unit 622 in computer device 110 can be used to execute the task processing method of the embodiments of this disclosure, for example:

[0314] Receive the first reward return request submitted by the first computer device;

[0315] The first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task. The first Merkle root is the Merkle root of a first Merkle tree generated based on the first hash value. The first Merkle path includes proof that the first Merkle root is a first hash set calculated from the first hash value.

[0316] When the first hash calculation result of the first hash set and the first hash value is the first Merkle root, obtain the historical hash value of the processed historical priority task;

[0317] When the historical hash value is different from the first hash value, the first reward corresponding to the first priority task is obtained;

[0318] The frozen first reward is returned to the first client, which is the client that requested the on-chain processing of the first priority task.

[0319] When the computer device 110 is used as a processing node, the central processing unit 622 in the computer device 110 can be used to execute the task processing method of the embodiments of this disclosure, for example:

[0320] Receive a third priority task sent by a third client, store the third priority task in the priority task pool, and the third priority task carries the third reward corresponding to the third priority task;

[0321] When multiple pending priority tasks obtained from the priority task pool include the third priority task, the sum of the rewards corresponding to each pending priority task is determined to obtain the third total reward.

[0322] A third Merkle tree is generated based on the unprocessed hash value of each of the aforementioned priority tasks.

[0323] Obtain the third Merkle root of the third Merkle tree, and the fifth block corresponding to the third Merkle root;

[0324] Based on the third total reward, the third Merkel root, and the fifth block, construct a third total reward freeze request;

[0325] Send the third total reward freeze request to the third computer device to freeze the third total reward corresponding to the third Merkel root through the third computer device.

[0326] This disclosure also provides a computer-readable storage medium for storing program code for executing the task processing methods of the foregoing embodiments.

[0327] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the task processing method described above. For example:

[0328] Receive the first reward return request submitted by the first computer device;

[0329] The first reward return request carries a first hash value, a first Merkle root, and a first Merkle path for a first priority task. The first Merkle root is the Merkle root of a first Merkle tree generated based on the first hash value. The first Merkle path includes proof that the first Merkle root is a first hash set calculated from the first hash value.

[0330] When the first hash calculation result of the first hash set and the first hash value is the first Merkle root, obtain the historical hash value of the processed historical priority task;

[0331] When the historical hash value is different from the first hash value, the first reward corresponding to the first priority task is obtained;

[0332] The frozen first reward is returned to the first client, which is the client that requested the on-chain processing of the first priority task.

[0333] For example, receiving a third priority task sent by a third client, storing the third priority task in the priority task pool, and the third priority task carrying the third reward corresponding to the third priority task;

[0334] When multiple pending priority tasks obtained from the priority task pool include the third priority task, the sum of the rewards corresponding to each pending priority task is determined to obtain the third total reward.

[0335] A third Merkle tree is generated based on the unprocessed hash value of each of the aforementioned priority tasks.

[0336] Obtain the third Merkle root of the third Merkle tree, and the fifth block corresponding to the third Merkle root;

[0337] Based on the third total reward, the third Merkel root, and the fifth block, construct a third total reward freeze request;

[0338] Send the third total reward freeze request to the third computer device to freeze the third total reward corresponding to the third Merkel root through the third computer device.

[0339] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0340] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0341] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0342] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0343] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0344] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0345] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0346] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0347] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0348] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A task processing method characterized by, The method comprises: receiving a first reward return request submitted by a first computer device; wherein the first reward return request carries a first hash value of a first priority task, a first Merkle tree root, and a first Merkle path, the first Merkle tree root being a Merkle tree root of a first Merkle tree generated according to the first hash value, and the first Merkle path including a first hash set proving that the first Merkle tree root is calculated from the first hash value; when the first hash set and the first hash calculation result of the first hash value are the first Merkle tree root, obtaining a historical hash value of a historical priority task that has been processed; when the historical hash value is different from the first hash value, obtaining a first reward corresponding to the first priority task; returning the first reward to a first client, the first client being a client requesting to chain the first priority task.

2. The task processing method according to claim 1, characterized by, The step of obtaining the historical hash value of the historical priority task that has been processed comprises: obtaining an ordering number of each target hash value in the first hash set; determining, in order of small to large, a target hash value with the smallest ordering number among target hash values that have not been subjected to hash calculation as a hash value to be calculated; determining a first hash calculation result of the first hash value and the hash value to be calculated; when there is a target hash value that has not been subjected to hash calculation among the target hash values, updating the first hash value to the first hash calculation result, and returning to the step of determining, in order of small to large, a target hash value with the smallest ordering number among target hash values that have not been subjected to hash calculation as a hash value to be calculated, until each target hash value is subjected to hash calculation to obtain a first hash calculation result; when the first hash calculation result is the first Merkle tree root, obtaining a historical hash value of a historical priority task that has been processed.

3. The task processing method according to claim 2, characterized by, The step of obtaining the historical hash value of the historical priority task that has been processed comprises: obtaining a first block corresponding to the first Merkle tree root; determining a second block with a preset number of blocks after the first block; determining, as historical priority tasks that have been processed, priority tasks stored in each block between the first block and the second block; obtaining a historical hash value of each historical priority task.

4. The task processing method according to claim 2, characterized by, The step of obtaining the historical hash value of the historical priority task that has been processed comprises: obtaining a storage hash value sent by any computer device, the storage hash value being a hash value sent when a historical priority task is chained; determining the storage hash value as a historical hash value of a historical priority task.

5. The task processing method according to any one of claims 1 to 4, characterized by, The step of obtaining the first reward corresponding to the first priority task comprises: identifying the first reward return request, so that the first reward return request carries a target mark, so that the first client feeds back the first priority task according to the target mark carried by the first reward return request; receiving the first priority task sent by the first client, the first priority task carrying a corresponding first reward; The first reward is obtained from the first priority task.

6. The task processing method according to any one of claims 1 to 4, characterized by, The returning of the first reward from the freezing to the first client comprises: From the frozen total rewards, a first total reward corresponding to the first Merkle tree root is determined. The first reward in the first total reward is unfrozen, and the first reward is returned to the first client.

7. The task processing method of claim 1, wherein, The method further comprises: receiving a second total reward freezing request sent by a second computer device, the second total reward freezing request comprising a second Merkle tree root, a third block corresponding to the second Merkle tree root, and a second total reward, the second Merkle tree root being a Merkle tree root of a second Merkle tree generated according to a second hash value of a second priority task; establishing a mapping relationship between the second Merkle tree root and the second total reward, and freezing the second total reward; determining a fourth block a preset number of blocks after the third block; when the second priority task is in a block between the third block and the fourth block, unfreezing a second reward corresponding to the second priority task in the second total reward; chaining the second priority task and returning the second reward to the second computer device.

8. A task processing method characterized by, comprises: receiving a third priority task sent by a third client, and storing the third priority task to a priority task pool, the third priority task carrying a third reward corresponding to the third priority task; when a plurality of to-be-processed priority tasks obtained from the priority task pool comprise the third priority task, determining a sum of rewards corresponding to each of the to-be-processed priority tasks to obtain a third total reward; generating a third Merkle tree based on to-be-processed hash values of each of the to-be-processed priority tasks; obtaining a third Merkle tree root of the third Merkle tree and a fifth block corresponding to the third Merkle tree root; constructing a third total reward freezing request according to the third total reward, the third Merkle tree root, and the fifth block; sending the third total reward freezing request to a third computer device, so as to freeze, by the third computer device, a third total reward corresponding to the third Merkle tree root.

9. The task processing method according to claim 8, characterized by, The generating of the third Merkle tree based on the to-be-processed hash values of each of the to-be-processed priority tasks comprises: performing hash calculation on two of the to-be-processed hash values to obtain a second hash calculation result; when the number of the second hash calculation results is not one, updating the to-be-processed hash values to the second hash calculation results, and returning to perform the step of performing hash calculation on two of the to-be-processed hash values to obtain a second hash calculation result until the number of the second hash calculation results is one, to obtain a third Merkle tree composed of a plurality of second hash calculation results obtained in the hash calculation process and the to-be-processed hash values.

10. The task processing method of claim 8, wherein, After the obtaining of the third Merkle tree root of the third Merkle tree and the fifth block corresponding to the third Merkle tree root, the method further comprises: determining a sixth block a specified number of blocks after the fifth block; when the third priority task is in a block between the fifth block and the sixth block, receiving the third reward returned by the third computer device.

11. The task processing method of claim 8, wherein, after the third total reward freezing request is sent to the third computer device, further comprising: obtaining a third Merkle path of a third hash value corresponding to the third priority task in the third Merkle tree; sending the third Merkle tree root and the third Merkle path to the third client.

12. A task processing apparatus characterized by comprising: comprising: a first receiving unit, configured to receive a first reward return request submitted by a first computer device; wherein the first reward return request carries a first hash value of a first priority task, a first Merkle tree root, and a first Merkle path, the first Merkle tree root being a Merkle tree root of a first Merkle tree generated according to the first hash value, and the first Merkle path including a first hash set proving that the first Merkle tree root is calculated from the first hash value; a first obtaining unit, configured to, when the first hash set and a first hash calculation result of the first hash value are the first Merkle tree root, obtain a historical hash value of a historical priority task that has been processed; a second obtaining unit, configured to, when the historical hash value is different from the first hash value, obtain a first reward corresponding to the first priority task; a return unit, configured to return the frozen first reward to a first client, the first client being a client requesting to perform on-chain processing on the first priority task.

13. A task processing apparatus characterized by comprising: comprising: a second receiving unit, configured to receive a third priority task sent by a third client and store the third priority task to a priority task pool, the third priority task carrying a third reward corresponding to the third priority task; a first determining unit, configured to, when a plurality of to-be-processed priority tasks obtained from the priority task pool include the third priority task, determine a sum of rewards corresponding to each to-be-processed priority task to obtain a third total reward; a generating unit, configured to generate a third Merkle tree based on to-be-processed hash values of each to-be-processed priority task; a third obtaining unit, configured to obtain a third Merkle tree root of the third Merkle tree and a fifth block corresponding to the third Merkle tree root; a constructing unit, configured to construct a third total reward freezing request according to the third total reward, the third Merkle tree root, and the fifth block; a first sending unit, configured to send the third total reward freezing request to a third computer device to freeze a third total reward corresponding to the third Merkle tree root through the third computer device.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the task processing method in any one of claims 1 to 7, or the task processing method in any one of claims 8 to 11.

15. A computer program product comprising computer programs or instructions, characterized in that, The computer program or instructions are executed by the processor to implement the task processing method in any one of claims 1 to 7, or the task processing method in any one of claims 8 to 11.

Images