Off-chain processing method and apparatus for blockchain tasks

Abstract

The present specification provides a method and device for off-chain processing of a blockchain task. The method is applied to an off-chain computing node corresponding to a blockchain node, and the method comprises: obtaining a cached historical blockchain task after startup is completed, the historical blockchain task being generated by the blockchain node before the off-chain computing node is shut down; obtaining a current blockchain task generated by the blockchain node, the current blockchain task being generated by the blockchain node after the off-chain computing node is shut down; and processing the historical blockchain task and the current blockchain task in parallel.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification belong to the technical field of blockchains, and particularly relate to a method and device for off-chain processing of blockchain tasks. BACKGROUND

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In a blockchain system, data blocks are combined into a chain-type data structure in a sequential manner according to time sequence, and the distributed ledger is ensured to be unalterable and unforgeable by means of cryptography.

[0003] Blockchain tasks generated by a blockchain network can be processed by off-chain computing nodes, but the off-chain computing nodes may be shut down due to some reasons during execution of the blockchain tasks. In related technologies, after startup is completed, the off-chain computing nodes process old tasks that have not been processed before shutdown and new tasks generated after shutdown in time sequence according to generation of the blockchain tasks. SUMMARY

[0004] The purpose of the present application is to provide a method and device for off-chain processing of blockchain tasks.

[0005] According to a first aspect of one or more embodiments of the present specification, a method for off-chain processing of blockchain tasks is provided, applied to an off-chain computing node corresponding to a blockchain node, and the method comprises:

[0006] After startup is completed, a cached historical blockchain task is obtained, the historical blockchain task being generated by the blockchain node before shutdown of the off-chain computing node;

[0007] A current blockchain task generated by the blockchain node is obtained, the current blockchain task being generated by the blockchain node after shutdown of the off-chain computing node;

[0008] The historical blockchain task and the current blockchain task are processed in parallel.

[0009] According to a second aspect of one or more embodiments of the present specification, a device for off-chain processing of blockchain tasks is provided, applied to an off-chain computing node corresponding to a blockchain node, and the device comprises:

[0010] A historical task obtaining unit is configured to obtain a cached historical blockchain task after startup is completed, the historical blockchain task being generated by the blockchain node before shutdown of the off-chain computing node;

[0011] The current task acquisition unit is configured to acquire a current blockchain task generated by the blockchain node, wherein the current blockchain task is generated by the blockchain node after the offline computing node is shut down;

[0012] The parallel processing unit is configured to parallelly process the historical blockchain task and the current blockchain task.

[0013] According to a third aspect of one or more embodiments of the present specification, an electronic device is provided, comprising:

[0014] a processor;

[0015] a memory for storing processor-executable instructions;

[0016] The processor implements the method according to any one of the first aspect by running the executable instructions.

[0017] According to a fourth aspect of one or more embodiments of the present specification, a computer readable storage medium is provided, which stores computer instructions, and the instructions are executed by a processor to implement the steps of the method according to any one of the first aspect.

[0018] In the present solution, after the startup of the offline computing node corresponding to the blockchain node is completed, the historical blockchain task generated and cached by the blockchain node before the offline computing node is shut down and the current blockchain task generated after the offline computing node is shut down can be acquired respectively, and then the historical blockchain task and the current blockchain task are parallelly processed.

[0019] It can be understood that the historical blockchain task is an old task acquired by the offline computing node before the offline computing node is shut down but not yet processed, and the current blockchain task is a new task acquired by the offline computing node after the offline computing node is shut down. Compared with the solution of processing the old task first in the related art, the present solution parallelly processes the historical blockchain task and the current blockchain task, which can shorten the interval time length from acquiring the current blockchain task to starting to process the task, i.e., shorten the waiting time length of the current blockchain task. It can be seen that the present solution can improve the execution efficiency of the current blockchain task, and helps to avoid the current blockchain task generated after the offline computing node is shut down from being accumulated in a large amount due to the inability to be processed in time. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0021] Figure 1FIG. 1 is a structural diagram of a chain off computing node provided by an example embodiment.

[0022] Figure 2 FIG. 2 is a flowchart of a chain off processing method of a blockchain task provided by an example embodiment.

[0023] Figure 3 FIG. 3 is a schematic diagram of a parallel processing process of a blockchain task provided by an example embodiment.

[0024] Figure 4 FIG. 4 is a structural diagram of an apparatus provided by an example embodiment.

[0025] Figure 5 FIG. 5 is a block diagram of a chain off processing device of a blockchain task provided by an example embodiment. DETAILED DESCRIPTION

[0026] In order to enable personnel in the technical field to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in combination with the drawings in the specification. Obviously, the described embodiments are only some of the embodiments of the specification, not all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the specification.

[0027] As described above, the chain off computing node in the related art usually executes historical blockchain tasks and current blockchain tasks in time sequence according to the time when the blockchain tasks are generated after startup is completed. The historical blockchain tasks are generated by the blockchain node before the chain off computing node is shut down, and the current blockchain tasks are generated by the blockchain node after the chain off computing node is shut down, that is, the generation time of the historical blockchain tasks is earlier than that of the current blockchain tasks. Therefore, if the way of processing old tasks preferentially proposed in the related art is adopted, the current blockchain tasks will be processed after all the historical blockchain tasks are processed.

[0028] Obviously, this way can cause the waiting time of the current blockchain tasks to be too long. For example, in the case that the number of historical blockchain tasks is large or the processing is slow, it takes a long time to process all the historical blockchain tasks, and therefore the current blockchain tasks need to wait for a long time to be processed. It can be seen that the way of processing historical blockchain tasks preferentially in the related art inevitably causes the waiting time of the current blockchain tasks to be too long, and even causes a large number of current blockchain tasks to be accumulated because they cannot be processed in time, thereby seriously affecting the execution efficiency of the current blockchain tasks.

[0029] To address the aforementioned problems in related technologies, this specification proposes an off-chain processing method for blockchain tasks. By processing historical and current blockchain tasks in parallel, the waiting time for the current blockchain task is shortened. This method can be applied to the off-chain computing nodes corresponding to blockchain nodes. The solution is described in detail below with reference to the accompanying drawings.

[0030] The off-chain computing node described in the embodiments of this specification can be composed of multiple functional modules. First, combined with... Figure 1 The structure of the off-chain computing node described in the embodiments of this specification is introduced. For example... Figure 1 As shown, the blockchain network consists of multiple blockchain nodes, from node A to node E, and each blockchain node can correspond to a specific off-chain computing node. Taking node A as an example, the off-chain computing node A corresponding to node A can include a scheduling engine and at least one computing engine framework. For example, the scheduling engine connects to n computing engine frameworks, such as computing engine frameworks 1 to n. Each computing engine framework and the m computing units it manages constitute a computing engine. For example, computing engine 1 includes computing engine framework 1 and computing units 11 to 13 (where m = 3), computing engine 2 includes computing engine framework 2 and computing units 21 to 22 (where m = 2), ..., computing engine n includes computing engine framework n and computing units n1 to nm, etc. It can be seen that any off-chain computing node contains a scheduling engine, at least one computing engine framework, and at least one computing unit. The scheduling engine can schedule each computing unit to execute corresponding blockchain tasks. Here, n and m are both integers greater than or equal to 1.

[0031] Any off-chain computing node corresponding to a blockchain node can be a computing entity logically composed of a corresponding scheduling engine, computing engine framework, and computing units. In terms of physical devices, the various components of this off-chain computing node can be deployed in the same or different physical devices; this specification does not limit this. For example, off-chain computing node A can be deployed in the node device to which the corresponding blockchain node belongs, i.e., off-chain computing node A and blockchain node A are deployed in the same node device. In this case, the scheduling engine, computing engine framework, and computing units included in the off-chain computing node can be corresponding functional modules running in that node device. Alternatively, the aforementioned scheduling engine and each computing engine framework can be functional modules running in that node device, while the computing units managed by each computing engine framework can run in other computing devices, thereby enabling remote invocation of the computing units by the computing engine framework. As another example, off-chain computing node A can also be deployed in a computing device outside the node device, while the corresponding computing engine framework and computing units can be deployed in that node device or other node devices, which will not be elaborated further.

[0032] It is understandable that the scheduling engine, various computing engine frameworks, and various computing units in off-chain computing nodes can all be regarded as functional modules that blockchain nodes can call. To achieve efficient management of these functional modules, they can be pre-registered to a unified service center. The functional modules contained in the off-chain computing nodes corresponding to each blockchain node in the blockchain network can be registered to the service center respectively. Specifically, computing units can register their computing type, access address, and other relevant information to the service center, and the service center can assign service identifiers to computing units for identification. After any computing unit is registered, the service center can maintain the aforementioned registration information for that computing unit. Similarly, the scheduling engine and computing engine framework in each off-chain computing node can be registered to the service center, referred to as registered services managed by the service center. The computing engine framework and computing units contained in any off-chain computing node that have been registered to the service center are the available services corresponding to the scheduling engine, and can be scheduled by the scheduling engine to execute blockchain tasks. In other words, the scheduling engine can schedule the blockchain tasks it receives to any computing unit managed by any computing engine framework corresponding to itself for execution.

[0033] The following is combined Figure 2 The off-chain processing method for blockchain tasks is shown, which explains the processing process (i.e., scheduling and execution process) of blockchain tasks. Figure 2 This is a flowchart illustrating an off-chain processing method for a blockchain task, as shown in an embodiment of this specification. This method is applied to the off-chain computing node corresponding to the blockchain node. Figure 2 As shown, the method includes steps 202-206.

[0034] Step 202: After startup is complete, retrieve the cached historical blockchain tasks, which were generated by the blockchain node before the off-chain computing node was shut down.

[0035] In one embodiment, the blockchain node and the off-chain computing node can be deployed in various ways. For example, the blockchain node and the off-chain computing node can reside in different processes within the same node device. The node device can run the blockchain node in one process and the off-chain computing node in another. It is understood that because the blockchain node and the off-chain computing node reside on the same node device, the time required for data interaction between them can be minimized; and because they belong to different processes, they can each invoke the implementation of the node device independently, helping to avoid mutual interference.

[0036] For another example, in the case where the off-chain computing node comprises a scheduling engine and a computing engine constituted by a computing engine framework and computing units managed thereby, the blockchain node and the scheduling engine can be different processes in the same node device respectively, while the computing engine framework and the computing units managed thereby can be in the same computing device or different computing devices outside the node device. This deployment manner not only enables the off-chain computing node and the blockchain node to be independent of each other, but also enables each functional module in the blockchain node to be independent, and only logically constitutes the off-chain computing node. This manner helps different off-chain computing nodes to cross-schedule the computing units, such as a computing unit being scheduled by a certain off-chain computing node to execute a certain blockchain task, or being scheduled by another off-chain computing node to execute another blockchain task. The execution times of the two blockchain tasks can or can not coincide (the computing unit can execute the tasks in series), and the present specification embodiments do not limit this.

[0037] In the present specification embodiments, the current start of the off-chain computing node can be a normal start, or can also be a restart after abnormal shutdown (or outage). Hereinafter, a restart after abnormal shutdown is taken as an example for description. Since the off-chain computing node is essentially a functional module running in a computing device, the shutdown of the off-chain computing node can be the stop of the functional module itself, or can also be the stop of the computing device as a whole, and the present specification embodiments do not limit this.

[0038] Since the scheduling engine is essentially a functional module running in a computing device (which can be the node device), the shutdown of the scheduling engine can be the stop of the functional module itself, or can also be the stop of the computing device as a whole, and the present specification embodiments do not limit this. Since the off-chain computing node contains only one scheduling engine, the off-chain computing node will not be able to normally process blockchain tasks after the shutdown of the scheduling engine, and thus the shutdown of the scheduling engine can be regarded as the shutdown of the off-chain computing node in which the scheduling engine is located, and this is hereby stated.

[0039] A blockchain node in a blockchain network can generate a blockchain task that needs to be processed off-chain by a computing node off-chain, for example, the blockchain node can generate a blockchain task by executing a smart contract or a blockchain transaction. For the above-mentioned blockchain task, the computing node off-chain can obtain and process it. As mentioned above, the computing node off-chain can include a scheduling engine and a computing engine composed of a computing engine framework and a computing unit, under this structure, the process of the computing node off-chain processing any blockchain task can include the process of the scheduling engine scheduling the blockchain task to the corresponding computing unit for execution, and returning the execution result thereof to the blockchain node. Wherein, if the execution result of any blockchain task has not been successfully returned to the blockchain node (such as the task has been obtained by the scheduling engine but has not been scheduled to the corresponding computing unit, the task has been scheduled to the corresponding computing unit for execution but has not been executed, the above-mentioned computing unit has returned the execution result to the scheduling engine but has not been successfully returned to the blockchain node by the scheduling engine, etc.), it can be considered that the blockchain task has not been processed.

[0040] In view of the fact that the processing process needs a certain time, in order to effectively manage the blockchain task that has not been processed, the computing node off-chain can cache the obtained blockchain task, such as caching it in the local storage space of the computing device or other storage space accessible to the computing node off-chain, etc. Wherein, the scheduling engine can maintain a task list for recording such tasks, the task list and the blockchain task obtained by the scheduling engine and the execution result of which has not been successfully returned to the blockchain node. In the case of obtaining any blockchain task, the scheduling engine can record the task in the above-mentioned task list; and in the case of returning the execution result of the task to the blockchain node (after processing), the scheduling engine can delete the task from the task list. Alternatively, the task state of any blockchain task can also be set to an unfinished state in the above-mentioned task list before the execution result thereof is successfully returned to the blockchain node; and in the case of successfully returning the execution result to the blockchain node, the task state thereof is adjusted to a completed state, the specific form of recording the blockchain task is not limited by the embodiments of the present specification.

[0041] At the shutdown moment, the off-chain computing node can not have completed processing the blockchain tasks that have been acquired and cached. For example, at the shutdown moment, there can be blockchain tasks in the task list that have not been completed processing, and thus after the startup is completed, the off-chain computing node can acquire such tasks from the list to continue processing them. In addition, the off-chain computing node that has completed startup also needs to acquire and process the blockchain tasks generated by the blockchain node after the off-chain computing node is shut down. In order to distinguish the blockchain tasks that the off-chain computing node needs to acquire, the embodiments of the present specification refer to the blockchain tasks generated before the shutdown of the scheduling engine as historical blockchain tasks, and refer to the blockchain tasks generated after the shutdown of the scheduling engine as current blockchain tasks.

[0042] As can be seen from the above, after the current startup is completed, the off-chain computing node can acquire historical blockchain tasks generated and cached before shutdown on the one hand, and can acquire current blockchain tasks generated after shutdown on the other hand. In other words, the acquisition of the historical blockchain tasks and the current blockchain tasks can be independently performed by the off-chain computing node after the startup is completed, and there is no necessary sequence between the two processes. Although Figure 1 Although the acquisition processes of the two are described as steps 102 and 104 respectively, the two acquisition processes can be implemented in parallel in time to improve the acquisition efficiency of the blockchain tasks.

[0043] After the startup is completed, the off-chain computing node can determine the tasks recorded in the task list of the scheduling engine (or the tasks in an unfinished state recorded therein) as the blockchain tasks. Alternatively, the historical blockchain tasks can also be read from the storage space of the off-chain computing node this time and recorded in the task list maintained by the scheduling engine, which will not be described in detail.

[0044] In an embodiment, in the case where the historical blockchain tasks are acquired, the scheduling engine can also initiate a state query request to the blockchain node, and determine whether the historical blockchain tasks need to be executed according to the query result returned by the blockchain node: and in the case where the query result indicates that the historical blockchain tasks are in an unfinished state, the historical blockchain tasks are taken as tasks to be processed, such as triggering a subsequent processing process for the tasks.

[0045] Of course, the query result can also indicate that the historical blockchain task is in a completed state, i.e., the blockchain node no longer needs the scheduling engine to process the historical blockchain task to obtain an execution result, and thus the scheduling engine does not need to process the task. Therefore, the scheduling engine can, in response to the query result indicating that the historical blockchain task is in a completed state, avoid processing the historical blockchain task, such as terminating the processing of the task and deleting the task, thereby not only effectively avoiding invalid processing of the task, but also saving time cost and resource cost for processing the current blockchain task, thereby improving the overall efficiency of the off-chain computing node in processing tasks.

[0046] At step 104, a current blockchain task generated by the blockchain node is obtained, the current blockchain task being generated by the blockchain node after the off-chain computing node is shut down.

[0047] In the embodiments described in the specification, the current blockchain task generated by the blockchain node after the off-chain computing node is shut down can also be divided into two categories in terms of generation time, one being a blockchain task generated from the moment the off-chain computing node is shut down to the moment the current startup is completed, and the other being a blockchain task generated after the current startup of the off-chain computing node is completed. It should be noted that the two types of historical blockchain tasks differ only in generation time, and there is no essential difference in the specific process of processing the two types of tasks by the off-chain computing node.

[0048] The off-chain computing node can obtain any current blockchain task by listening to events. For example, the blockchain node can generate a task allocation event containing the current blockchain task in the process of executing a blockchain transaction or a smart contract, so that the scheduling engine can obtain the current blockchain task by listening to the task allocation event. The off-chain computing node can listen to the task allocation event generated by the blockchain node, and in response to listening to the event, determine the participant of the current blockchain task contained in the task allocation event. Further, the current blockchain task can be determined as the current blockchain task in a case where it is determined that the current blockchain task is allocated to the blockchain member to which the blockchain node belongs (i.e., the blockchain node is a participant of the current blockchain task). The listening process can be implemented by the scheduling engine in the off-chain computing node, i.e., the scheduling engine can obtain the current blockchain task by listening to the task allocation event.

[0049] It can be understood that the process of the scheduling engine obtaining the historical blockchain task before shutdown (the task is not a historical blockchain task at the time of obtaining the historical blockchain task) is not essentially different from the process of obtaining the current blockchain task after startup is complete, and will not be repeated. In fact, the historical blockchain task and the current blockchain task described in the embodiments of the present specification only differ in generation timing and obtaining method, and there is no essential difference in the process of the scheduling engine processing the obtained historical blockchain task and the current blockchain task.

[0050] Step 106, the historical blockchain task and the current blockchain task are processed in parallel.

[0051] In the present solution, the off-chain computing node corresponding to the blockchain node can obtain the historical blockchain task generated and cached by the blockchain node before shutdown and the current blockchain task generated after shutdown of the off-chain computing node after startup is complete, and then process the historical blockchain task and the current blockchain task in parallel.

[0052] It can be understood that the historical blockchain task is an old task obtained by the off-chain computing node before shutdown but not yet processed, and the current blockchain task is a new task obtained by the off-chain computing node after shutdown. Compared with the solution of the related art that prioritizes processing old tasks, the present solution processes the historical blockchain task and the current blockchain task in parallel, which can shorten the interval between obtaining the current blockchain task and starting to process the task by the off-chain computing node, i.e., effectively shortens the waiting time of the current blockchain task. It can be seen that the present solution can improve the execution efficiency of the current blockchain task and help avoid the current blockchain task generated after shutdown from being accumulated in large quantities due to being unable to be processed in time.

[0053] It can be understood that the at least one historical blockchain task obtained by the foregoing method constitutes a historical task set, and the at least one current blockchain task obtained constitutes a current task set. In an embodiment, the off-chain computing node can alternately select historical blockchain tasks and current blockchain tasks from the historical task set and the current task set, respectively, and execute the selected blockchain tasks in the order of selection of the blockchain tasks, thereby effectively realizing parallel processing of the historical blockchain tasks and the current blockchain tasks. For the historical task set, the off-chain computing node can sequentially and randomly select each historical blockchain task to simplify the selection process, or can select each historical blockchain task in the order of generation time of the task to ensure that the execution order of each historical blockchain task is consistent with the generation order among the historical blockchain tasks. Similarly, for the current task set, the off-chain computing node can sequentially and randomly select each current blockchain task, or can select each current blockchain task in the order of generation time of the task.

[0054] In an embodiment, the obtained respective blockchain tasks can be placed in corresponding task queues, so as to realize parallel processing of the blockchain tasks based on the task queues. For example, the off-chain computing node can sequentially input respective historical blockchain tasks into a first queue in chronological order of generation of the respective historical blockchain tasks, and sequentially input respective current blockchain tasks into a second queue in chronological order of generation of the respective current blockchain tasks; then, the historical blockchain tasks and the current blockchain tasks can be obtained from the first queue and the second queue respectively, and the obtained respective blockchain tasks can be sequentially processed in the order of obtaining.

[0055] For this mode, it can be understood that, on the one hand, the historical blockchain tasks are input into the first queue in chronological order of generation, by taking advantage of the fixed order of the queue itself, so that the respective historical blockchain tasks in the first queue are sequentially arranged in the chronological order; similarly, the current blockchain tasks are input into the second queue in chronological order of generation, so that the respective current blockchain tasks in the second queue are sequentially arranged in the chronological order. Therefore, the respective historical blockchain tasks sequentially obtained and processed from the first queue by the off-chain computing node conform to the chronological order, and the respective current blockchain tasks sequentially obtained and processed from the second queue also conform to the chronological order, so that the processing order of the same type of blockchain tasks conforms to the chronological order of generation, which can effectively avoid processing errors that can be caused by inconsistency between the processing order and the generation order of the same type of blockchain tasks. On the other hand, because the historical blockchain tasks and the current blockchain tasks are alternately obtained and the obtained respective blockchain tasks are sequentially processed in the order of obtaining, the historical blockchain tasks and the current blockchain tasks can be alternately processed, thereby effectively realizing parallel processing of the blockchain tasks.

[0056] In order to avoid task congestion that can be caused by excessive number of the same type of blockchain tasks, the first queue and the second queue can be set with a number threshold. In other words, the number of the historical blockchain tasks in the first queue and the number of the current blockchain tasks in the second queue do not exceed the corresponding number threshold. For example, the number threshold of the first queue can be set as S1, and the number threshold of the second queue can be set as S2, at this time, the first queue can simultaneously save at most S1 historical blockchain tasks, and the second queue can simultaneously save at most S2 current blockchain tasks. S1 and S2 are both positive integers greater than or equal to 1, and in the application of the scheme, the specific values thereof can be adjusted according to specific circumstances, which are not limited by the embodiments of the present disclosure.

[0057] In addition, the main thread corresponding to the off-chain computing node can include a first sub-thread, a second sub-thread, and a third sub-thread. Based on this, the first sub-thread can sequentially input each historical blockchain task into a first queue, and the second sub-thread can sequentially input each current blockchain task into a second queue; and the third sub-thread can alternately obtain the historical blockchain task and the current blockchain task from the first queue and the second queue, respectively. The main thread of the off-chain computing node can uniformly manage the above-mentioned sub-threads, so that the sub-threads cooperate with each other to complete the parallel processing of the historical blockchain task and the current blockchain task. In this way, the off-chain computing node can complete different steps in the task processing process through different threads, so that each step is executed independently and does not affect each other, which is helpful for the modular implementation of parallel processing, thereby improving the efficiency of parallel processing.

[0058] As shown in Figure 3 The first sub-thread can obtain each historical blockchain task in the local cache (such as the task list maintained by the aforementioned scheduling engine) of the off-chain computing node and sequentially input it into the first queue. Similarly, the second sub-thread can obtain each current blockchain task from the blockchain node through the aforementioned event listening and sequentially input it into the second queue. Further, the third sub-thread can alternately obtain the historical blockchain task and the current blockchain task from the first queue and the second queue, and sequentially input each historical blockchain task obtained into the to-be-processed queue. Obviously, the to-be-processed queue records each historical blockchain task and current blockchain task waiting for subsequent processing. Further, the off-chain computing node (such as the scheduling engine or the third sub-process) can sequentially obtain each blockchain task output by the to-be-processed queue and perform subsequent processing on it.

[0059] As mentioned earlier, there is no essential difference between the specific processing process of the off-chain computing node for the historical blockchain task and the current blockchain task. In fact, in the process of parallel processing, the off-chain computing node can perform the same subsequent processing process on the obtained historical blockchain task and current blockchain task, and the subsequent processing process of any blockchain task in the historical blockchain task and the current blockchain task includes scheduling and execution.

[0060] As mentioned earlier, the off-chain computing node can include a scheduling engine and a computing engine composed of a computing engine framework and a computing unit managed thereby. Based on this structure, the scheduling and execution can be implemented, that is, the scheduling engine can schedule the blockchain task to the corresponding computing unit for execution, and return the execution result to the blockchain node. The following Figure 1The internal structure of the off-chain computing node is shown, and the scheduling and execution process of any one of the historical blockchain task and the current blockchain task (hereinafter referred to as the target blockchain task) is described in detail.

[0061] As mentioned earlier, the scheduling engine in the off-chain computing node corresponds to at least one computing engine, and in an embodiment, the scheduling engine can schedule (i.e., distribute) the historical blockchain task to the corresponding computing engine for execution. For example, the scheduling engine can schedule the historical blockchain task to the target computing engine that matches the target blockchain task for execution, and receive the execution result of the target blockchain task returned by the computing engine. In this way, the scheduling engine can control the execution of the target blockchain task by the target computing engine that matches the target blockchain task, thereby facilitating the smooth and efficient processing of the task.

[0062] In this case, the off-chain computing node includes a scheduling engine and at least one computing unit, the scheduling engine can determine the target computing unit that matches the target blockchain task from each computing unit included in the off-chain computing node, and the computing engine framework of the target computing unit is the target computing engine framework, and the target computing engine framework and the target computing unit belong to the target computing engine. As can be seen, in the case where the scheduling engine determines the target computing unit, the corresponding target computing engine framework and target computing engine are also determined. Further, the scheduling engine can send the target blockchain task to the target computing engine framework, and the target computing engine framework forwards the target blockchain task to the target computing unit for execution by the target computing unit if it is determined that the target computing unit is in an available state.

[0063] For example, if the scheduling engine determines that the target computing unit that matches the target blockchain task is the computing unit 21 shown in Figure 1 Figure 1 The target computing engine framework is the computing engine framework 2, and the target computing engine is the computing engine 2. At this time, the scheduling engine can issue the target blockchain task to the computing engine framework 2, and the computing engine framework 2 forwards the task to the computing unit 21 for execution. In the above process, the scheduling engine is used to determine which computing unit to execute the target blockchain task (i.e., to determine the target computing unit), and the target computing engine framework is used to forward the task to the target computing unit, and through the cooperation of the two, the accurate and efficient scheduling of the blockchain task can be achieved.

[0064] ​In addition, to ensure that the determined target computing unit can perform the target blockchain task as much as possible, the scheduling engine can determine available services that are allowed to be invoked by the scheduling engine according to available service information maintained by the scheduling engine, the available services including the computing engine framework and each computing unit managed thereby, and then determine the target computing unit from the each computing unit that matches the target blockchain task. Each computing unit determined according to the available service information can be invoked by the scheduling engine, and thus the target computing unit determined from the each computing unit can also be invoked by the scheduling engine, thereby facilitating the target blockchain task to be performed smoothly.

[0065] As described above, the scheduling engine, the computing engine framework, and the computing unit in the off-chain computing node are all pre-registered to the service center, and thus the registered services corresponding to the scheduling engine include the computing engine framework and the computing unit registered to the service center. The available service information maintained by the scheduling engine indicates the computing engine framework and the computing unit in the registered services that are allowed to be invoked by the scheduling engine. In the case of a change in the available services such as the computing engine framework or the computing unit, the scheduling engine can update the available service information maintained locally to ensure that the available services indicated by the available service information are indeed available (i.e., can be invoked by the scheduling engine). For example, the scheduling engine can obtain a service change message from the service center indicating the registered services after the change, and then update the available service information maintained by the scheduling engine according to the message. In this way, the scheduling engine can perceive the change in the available services in a timely manner, and thus ensure the accuracy of the available service information by updating the available service information, and further improve the accuracy of the subsequent determination of the target computing unit and the target computing engine framework.

[0066] The service change message can be sent by the service center to the scheduling engine in response to a change in the registered service. For example, the scheduling engine can specify the registered services it is interested in when it registers with the service center, such as each computing engine framework and computing unit in a chain computing node can specify each of them as the registered service it is interested in. On this basis, the service center can actively send the service change message about the service to the scheduling engine in the case of any change (such as addition, deletion, registration information update, etc.) in the registered service that the scheduling engine is interested in. In this way, the service center can timely inform the scheduling engine after the registered service of the personnel that the scheduling engine is interested in changes, so that it can update the relevant information of the service it maintains in time. For the above target computing engine framework, the service center actively sends the service change message to the scheduling engine in the case of shutdown, so that the scheduling engine can timely and accurately learn that the target computing engine framework has been shut down, thereby helping the scheduling engine to timely recover the historical blockchain task that cannot be continued by the target computing unit.

[0067] Alternatively, the scheduling engine can also initiate a change query request to the service center according to a preset query period, and the service center can not return a response message or only return an empty message to the scheduling engine in the case that the service state of each registered service does not change. In the case that the service state of at least one registered service changes, the service center can return a service change message to the scheduling engine for the changed registered service. For example, the service center can return the service change message to the scheduling engine in the case of determining that the registered service changes, so as to inform the scheduling engine of the above change, and facilitate it to update the available service information in time.

[0068] In an embodiment, any computing unit has a corresponding computing type, which can be regarded as the type of task that the computing unit can execute. In the case that a computing engine contains multiple computing units, the computing types of these computing units can be the same or different. Similarly, in the case that the chain computing node contains multiple computing units, the computing types of these computing units can also be the same or different. To further ensure that the target computing unit successfully executes the target blockchain task and improve the execution efficiency of the task, the scheduling engine can determine the target computing unit according to the computing type. For example, the scheduling engine can determine the target computing type corresponding to the target blockchain task, and then determine the computing unit with the target computing type in the above each computing unit as the target computing unit. In this way, it can be ensured that the computing type of the target computing unit executing the historical blockchain task matches the target computing type of the task, which helps to avoid execution errors and improves the execution efficiency to some extent.

[0069] In order to record the calculation types of the calculation units, the scheduling engine can maintain a service type list, which records the calculation types of the calculation units included in the off-chain computing node. The scheduling engine can determine the target calculation unit based on the service type list. For example, the scheduling engine can determine the target calculation type of the historical blockchain task, query the target calculation type in the service type list, and determine the calculation unit corresponding to the target calculation type as the target calculation unit. The calculation type and the target calculation type can be a forwarding type, an MFT (Managed File Transfer) type, a privacy calculation type, a data query type, etc., which are not limited in the embodiments of the present application.

[0070] In an embodiment, any of the available services can be in an available state or an unavailable state at any time. For example, if the calculation unit 11 is down (normal shutdown or abnormal downtime), the calculation unit cannot perform any task, and can be considered to be in an unavailable state. If the calculation unit 11 is executing a task, the calculation unit cannot execute other tasks including the historical blockchain task at the current time, so the calculation unit 11 is also in an unavailable state at this time. For another example, if the calculation engine framework 2 is down, the calculation engine framework cannot perform any task, and can be considered to be in an unavailable state. Alternatively, if the calculation units 21 and 22 managed by the calculation engine 2 are in an unavailable state, there is no calculation unit that can be called by the calculation engine framework to perform a task at the current time, so the calculation engine framework 2 is also in an unavailable state at this time.

[0071] For each of the available services, the scheduling engine can maintain the service state thereof. It can be understood that if the historical blockchain task is scheduled to the target calculation unit in an unavailable state, the task can not be successfully executed. Therefore, the scheduling engine can also forward the target blockchain task to the target calculation unit for execution by the target calculation engine framework when the target calculation unit and the target calculation engine framework are in an available state. Further, when the target calculation engine framework is down, the scheduling engine can update the service state of the calculation engine framework and each calculation unit managed thereby to an unavailable state. Alternatively, when the target calculation unit is down, the scheduling engine can update the service state of the calculation unit to an unavailable state. It can be seen that the above method takes “the target calculation engine framework and the target calculation unit are in an available state” as a prerequisite for “scheduling the historical blockchain task to the target calculation unit by the target calculation engine framework”. Based on this, the scheduled historical blockchain task can be successfully executed by the target calculation unit as much as possible, and the scheduling and execution process can be prevented from being erroneous.

[0072] In addition, "the target computing unit and the computing engine framework managing the computing unit being in an available state" can also be taken as a precondition of "determining the computing unit as the target computing unit". For example, the scheduling engine can further determine the current state of the computing unit and the computing engine framework managing the computing unit based on the locally maintained service state in the case of determining that a certain computing unit matches the target blockchain task, and determine the computing unit as the target computing unit and the computing engine framework managing the computing unit as the target computing engine framework in the case of determining that the computing unit and the computing engine framework managing the computing unit are both in an available state, and then forward the historical blockchain task to the target computing unit for execution through the target computing engine framework. This way can pre-position the judgment process of the above-mentioned service state, which helps to further ensure the smooth execution of the blockchain task and improves the execution efficiency to a certain extent.

[0073] In an embodiment, considering that the target computing unit needs to consume certain resources to execute the target blockchain task, in order to improve the success rate of the target computing unit executing the target blockchain task as much as possible, the scheduling engine can also determine the target computing unit according to the resource amount of the computing unit. For example, the scheduling engine can determine the current available resource amount of each computing unit in the off-chain computing node respectively, and select the target computing unit from the computing units whose current available resource amount meets the execution condition of the blockchain task. The execution condition can include that the current available resource amount is not less than a resource threshold, or the current available resource amount is not less than the resource amount required for executing the blockchain task, etc. In addition, the above-mentioned execution condition can be recorded in the target blockchain task, such as in the case of the task being executed by the blockchain node to generate a blockchain transaction or a smart contract, the execution condition can be recorded in the blockchain transaction or the smart contract, or it can be determined by the blockchain node according to the intermediate parameters of the execution process. Alternatively, the above-mentioned execution condition can also be uniformly set by the user of the blockchain node or the administrator of the blockchain network for at least one blockchain task, such as uniformly setting the memory threshold corresponding to the off-chain privacy computing type of the blockchain task as 16M, etc. The embodiments of the present application do not limit the specific content of the above-mentioned execution condition and the determination method thereof. Through this way, the available resources in the execution process of the target blockchain task can be determined, which helps the target computing unit to execute the task smoothly and efficiently.

[0074] It should be noted that the above-mentioned multiple ways of determining the target computing unit can be used individually or simultaneously. For example, the computing unit in the available state can be determined in the computing unit of the target computing type, and the target computing unit can be further selected therefrom. Alternatively, the computing unit whose current available resource amount meets the execution condition of the blockchain task can be determined in the computing unit of the target computing type, and the target computing unit can be further selected from the determined computing units. Of course, other ways of determining the target computing unit can also be used, which will not be described herein.

[0075] After obtaining the target blockchain task forwarded by the target computing engine framework, the target computing unit can execute the task according to necessary data. For example, the data required for executing the target blockchain task can be carried in the task, wherein the data can be determined by the blockchain node in the process of generating the target blockchain task and recorded in the generated task; the data can also be sent to the scheduling engine in association with the target blockchain task, and the scheduling engine can also issue the data to the target computing unit in association with the target computing unit. In this scenario, the target computing unit can directly use the data to execute the target blockchain task, thereby realizing the fast execution of the task. For another example, the data required for executing the target blockchain task can also need to be obtained from other data management parties. In this scenario, the target computing unit can initiate a data obtaining request for the target blockchain task to the data management party, and execute the task according to the data returned by the data management party. Of course, the execution of the target blockchain task can require multiple data from different sources, for example, one data is carried by the target blockchain task, and another data needs to be obtained from the data management party, which is not limited by the embodiments of the present disclosure.

[0076] In addition, corresponding to the aforementioned forwarding type, the target computing unit can also forward the target blockchain task to a preset execution party for execution, and obtain the execution result returned by the preset execution party. At this time, although the target blockchain task is actually executed by the preset execution party, relative to the off-chain computing node, the scheduling engine or the computing engine framework, the execution effect of "the target computing unit executes the target blockchain task" is still presented, and therefore the task can be considered as executed by the target computing unit.

[0077] In an embodiment, for the target blockchain task, the scheduling engine can record it in a task list maintained by itself, determine a target computing unit and a target computing engine framework, and then issue the task to the target computing engine framework. Upon receiving the target blockchain task issued by the scheduling engine, the target computing engine framework can record the task in a task list maintained by itself, and forward the task to the target computing unit for execution. Upon completion of the target blockchain task executed by the target computing unit, the execution result can be returned to the target computing engine framework. Upon receiving the execution result returned by the target computing unit, the target computing engine framework can record it in a result list maintained by itself, and attempt to return the execution result to the scheduling engine. The target computing engine framework can return each execution result to the scheduling engine in the order of the time when each execution result is received by the target computing engine framework, so as to avoid a long time consumption for returning the result. Until the execution result of the target blockchain task is successfully returned to the scheduling engine (the scheduling engine can return a confirmation message to the computing engine framework upon successfully receiving the execution result), the target computing engine framework can delete the target blockchain task recorded in the task list maintained by itself, and delete the execution result of the task recorded in the result list maintained by itself.

[0078] Similarly, upon receiving the execution result returned by the target computing engine framework, the scheduling engine can record the execution result in a result list maintained by itself, and attempt to upload the execution result to a blockchain node. The scheduling engine can upload each execution result to the blockchain node in the order of the time when each execution result is received by the scheduling engine, so as to avoid a long time consumption for uploading the result. Alternatively, in the case of failure due to some reasons, the scheduling engine can wait for a period of time and then attempt to upload again, until the uploading is successful. Upon successfully uploading the execution result of the target blockchain task to the blockchain node (the blockchain node can also return a confirmation message to the scheduling engine upon successfully receiving the execution result), the scheduling engine can delete the target blockchain task recorded in the task list maintained by itself, and delete the execution result of the task recorded in the result list maintained by itself.

[0079] From the scheduling process of the blockchain task and the returning process of the execution result, it can be seen that if the target blockchain task is a historical blockchain task, the scheduling engine may not have received the execution result of the task returned by the computing engine framework before the scheduling engine is shut down, or the execution result may have been received but has not been successfully uploaded to the blockchain node. Therefore, the scheduling engine can process the historical blockchain task after being started according to whether the execution result has been received (that is, whether the execution result has been recorded in the task list maintained by the scheduling engine). For example, in the case that the execution result of any historical blockchain task is recorded in the result list maintained by the scheduling engine, the scheduling engine can return the execution result to the blockchain node without processing the historical blockchain task in the foregoing manner. In the case that the execution result of any historical blockchain task is not recorded in the result list maintained by the scheduling engine, the scheduling engine can schedule the historical blockchain task to the computing unit in the computing engine for execution, and record the execution result returned by the computing engine to the result list and return it to the blockchain node.

[0080] It can be seen that in the case that the execution result of the historical blockchain task is recorded in the result list maintained by the scheduling engine, the scheduling engine does not need to schedule the task to the computing unit. That is, because the execution result of the historical blockchain task has been returned to the scheduling engine before the scheduling engine is shut down, the scheduling engine can directly upload the execution result to the blockchain node without repeating the scheduling and execution of the task. In the case that the execution result is not recorded in the result list maintained by the scheduling engine, the scheduling engine can determine the target computing unit and the target computing engine framework in the manner of the foregoing embodiments, then schedule the task to the target computing unit through the target computing engine framework for execution, receive the execution result returned by the target computing unit through the target computing engine framework, and further upload the result to the blockchain node. In addition, in the case that it is determined that the execution result is successfully returned to the blockchain node, the scheduling engine can delete the execution result recorded in the result list maintained by the scheduling engine.

[0081] Upon receiving the execution result of the target blockchain task, the off-chain computing node can return it to the blockchain node for use. Specifically, if the blockchain transaction generating the target RR instructs the blockchain node to invoke a workflow defined in the smart contract, the execution result can be used by JJ to advance that workflow. For example, the workflow corresponding to the aforementioned blockchain transaction may contain multiple task nodes with dependencies between them, allowing the workflow to proceed based on these dependencies. The target blockchain task can correspond to any of these task nodes, and upon receiving the execution result of the target RR, JJ can advance the workflow to execute another RR that depends on any of the task nodes. In this way, JJ can sequentially execute the RRs corresponding to each task node according to the preset steps of the workflow until the blockchain transaction is completed.

[0082] In one embodiment, the blockchain node described in this specification may belong to a blockchain subnet managed by the blockchain mainnet. For example... Figure 1 As shown, if some blockchain nodes nodeA to nodeE in a certain blockchain network (denoted as net1, not shown in the figure) have a need for small-scale interaction, then a new blockchain network (denoted as net2, i.e., ...) can be established between them. Figure 1 (The blockchain network shown is illustrated.) Let's assume net1 contains 12 nodes, nodes A through L. At least one of nodes A through E, corresponding to a user or the administrator of net1, can initiate a subnet generation transaction within net1. Each node A through L in net1 can then execute this transaction. During transaction execution, nodes A through E can determine themselves as participants in net2 based on the transaction content, while other nodes F through L can determine they are not participants in net2. Based on this, nodes A through E can establish net2 among themselves using the consensus link of net1, while nodes F through L will not participate in this subnet formation process. For net2 established in this way, it can be managed by net1. In this case, net1 is the main blockchain network, and net2 is the subnet.

[0083] In this scenario, the off-chain computing node corresponding to the blockchain node A in the blockchain subnetwork, upon obtaining the execution result of the historical blockchain task and / or the current blockchain task, can submit the execution result to the blockchain main network to store the execution result in the blockchain main network. In this way, the blockchain main network for managing the blockchain subnetwork can also store the execution result of the blockchain task corresponding to the blockchain node in the blockchain subnetwork, thereby relying on the data management capability of the blockchain main network to store the execution result, which helps to improve the storage security of the data.

[0084] Figure 4 is a schematic structural diagram of an apparatus provided by an example embodiment. Please refer to Figure 4 At the hardware level, the apparatus includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, and can also include other hardware required by the business. One or more embodiments of the present specification can be implemented in a software manner, such as reading a corresponding computer program from the non-volatile memory 410 into the memory 408 by the processor 402 and then running. Of course, in addition to the software implementation, one or more embodiments of the present specification do not exclude other implementation manners, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or a logic device.

[0085] As shown in Figure 5 , Figure 5 is a block diagram of an off-chain processing device of a blockchain task provided by an example embodiment of the present specification. The device can be applied to an apparatus as shown in Figure 4 to implement the technical solutions of the present specification. The device is applied to an off-chain computing node corresponding to a blockchain node, and the device includes:

[0086] A historical task acquisition unit 501 is configured to acquire a cached historical blockchain task after startup is completed, wherein the historical blockchain task is generated by the blockchain node before the off-chain computing node is shut down;

[0087] A current task acquisition unit 502 is configured to acquire a current blockchain task generated by the blockchain node, wherein the current blockchain task is generated by the blockchain node after the off-chain computing node is shut down;

[0088] A parallel processing unit 503 is configured to parallel process the historical blockchain task and the current blockchain task

[0089] Optionally, the current task acquisition unit 502 is further configured to:

[0090] In response to listening to a task allocation event generated by the blockchain node performing a blockchain transaction, in a case where it is determined that a blockchain task contained in the task allocation event is allocated to a blockchain member to which the blockchain node belongs, the blockchain task is determined as the current blockchain task.

[0091] Optionally,

[0092] The queue input unit 504 is further configured to input each historical blockchain task into the first queue in a time sequence in which the historical blockchain task is generated, and input each current blockchain task into the second queue in a time sequence in which the current blockchain task is generated.

[0093] The parallel processing unit 503 is further configured to acquire each historical blockchain task from the first queue and each current blockchain task from the second queue in sequence, and execute each acquired blockchain task in sequence.

[0094] Optionally, the main thread corresponding to the off-chain computing node includes a first sub-thread, a second sub-thread, and a third sub-thread,

[0095] The queue input unit 504 is further configured to input each historical blockchain task into the first queue by the first sub-thread, and input each current blockchain task into the second queue by the second sub-thread.

[0096] The parallel processing unit 503 is further configured to acquire each historical blockchain task from the first queue and each current blockchain task from the second queue alternately by the third sub-thread.

[0097] Optionally, the number of historical blockchain tasks in the first queue and the number of current blockchain tasks in the second queue do not exceed a corresponding number threshold.

[0098] Optionally, the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and a computing unit managed thereby, the scheduling engine is configured to schedule a blockchain task to the computing engine for execution; and the parallel processing unit 503 is further configured to:

[0099] The scheduling engine is configured to determine a target computing unit matched with the any blockchain task from the computing unit, and send the any blockchain task to a target computing engine framework to which the target computing unit belongs.

[0100] The target computing engine framework is configured to, in a case where it is determined that the target computing unit is in an available state, forward the any blockchain task to the target computing unit.

[0101] The target computing unit is configured to execute the any blockchain task.

[0102] Optionally, the parallel processing unit 503 is further configured to:

[0103] determine, by the scheduling engine, available services allowed to be invoked by the scheduling engine according to available service information maintained by the scheduling engine, the available services comprising computing engine frameworks and respective computing units managed by the computing engine frameworks;

[0104] determine, by the scheduling engine, target computing units matching the any blockchain task from the respective computing units.

[0105] Optionally, the parallel processing unit 503 further comprises:

[0106] a change message obtaining unit 505 configured to obtain, by the scheduling engine, a service change message from a service center, the service change message being used to indicate changed registered services, the registered services comprising computing engine frameworks and computing units registered to the service center;

[0107] a service information updating unit 506 configured to update, by the scheduling engine, the available service information according to the service change message, the available service information being used to indicate computing engine frameworks and computing units allowed to be invoked by the scheduling engine from the registered services.

[0108] Optionally, the change message obtaining unit 505 is further configured to:

[0109] initiate, by the scheduling engine, a change query request to the service center according to a preset query period, and receive a service change message returned by the service center in a case where it is determined that the registered services have changed; or

[0110] receive, by the scheduling engine, a service change message sent by the service center in response to the registered services having changed.

[0111] Optionally, the available service information comprises computing types of the computing units, and the parallel processing unit 503 is further configured to:

[0112] determine, by the scheduling engine, a target computing type corresponding to the any blockchain task;

[0113] determine, by the scheduling engine, computing units with the target computing type from the respective computing units as the target computing units.

[0114] Optionally, the parallel processing unit 503 is further configured to:

[0115] determine, by the scheduling engine, current available resource amounts of respective computing units in the off-chain computing nodes respectively;

[0116] selecting, by the scheduling engine, a target computing unit from the computing units whose current available resource amount satisfies an execution condition of the blockchain task, the execution condition comprising: the current available resource amount being not less than a resource threshold, or the current available resource amount being not less than a resource amount required for executing the blockchain task.

[0117] Optionally, the parallel processing unit 503 is further configured to:

[0118] initiating, by the target computing unit, a data acquisition request for the any blockchain task to a data management party, and executing the any blockchain task according to data returned by the data management party; and / or,

[0119] executing, by the target computing unit, the any blockchain task according to data carried by the any blockchain task.

[0120] Optionally, the device further comprises:

[0121] a task recording and deleting unit 507 configured to record, by the scheduling engine, the acquired any blockchain task in a first task list maintained by itself and set a task state of the any blockchain task as an unfinished state; and, in response to successfully submitting an execution result of the any blockchain task to the blockchain node, delete the blockchain task recorded in the first task list or update the task state of the blockchain task as a completed state; and / or,

[0122] a result recording and deleting unit 508 configured to record, by the target computing engine framework, the any blockchain task sent by the scheduling engine in a second task list maintained by itself and set a task state of the any blockchain task as an unfinished state; and, in response to successfully returning the execution result of the any blockchain task to the scheduling engine, delete the blockchain task recorded in the second task list or update the task state of the blockchain task as a completed state.

[0123] Optionally,

[0124] the blockchain node and the off-chain computing node are respectively different processes in a same node device; or,

[0125] in a case where the off-chain computing node comprises a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the computing engine framework, the blockchain node and the scheduling engine are respectively different processes in a same node device, and the computing engine framework and the computing units managed by the computing engine framework are in the same or different computing devices other than the node device.

[0126] Optionally, the blockchain node belongs to a blockchain subnet managed by a blockchain main network, and the device further comprises:

[0127] The result storage unit 509 is configured to submit the execution result of the historical blockchain task and the current blockchain task to the main network of the blockchain, so as to store the execution result in the main network of the blockchain.

[0128] Optionally, the current blockchain task comprises at least one of the following:

[0129] The blockchain task generated by the blockchain node from the moment when the off-chain computing node is shut down to the moment when the current start is completed;

[0130] The blockchain task generated by the blockchain node after the current start of the off-chain computing node is completed.

[0131] Optionally, the current start of the off-chain computing node is a normal start or a restart after an abnormal shutdown.

[0132] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) such as a field programmable gate array (FPGA) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a piece of PLD by the designer programming it by himself, without having to ask a chip manufacturer to design and manufacture a special integrated circuit chip. Moreover, instead of manually fabricating an integrated circuit chip, this programming is now mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing a program, and the original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0133] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0134] The systems, apparatuses, modules or units illustrated by the above-described embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, computers implementing the functions of the above-described embodiments can be personal computers, laptop computers, in-vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0135] Although the method operations of the embodiments of the present disclosure are described in a particular, sequential order, one or more of the method operations can be omitted, or the method operations can be performed in an order other than the described order. Additionally, one or more of the method operations can be performed concurrently, or with partial concurrence. Furthermore, one or more of the method operations can be performed by different entities, or over different time periods. The term "including" as used herein is intended to mean "comprising," such that the process, method, article, or apparatus that includes elements in addition to those specified can still be deemed to include the specific elements. The term "coupled" as used herein is intended to mean two or more entities that have a direct or indirect connection between or among each other.

[0136] For the sake of description, the above-described apparatuses are described with various modules for convenience. Of course, when implementing one or more embodiments of the present disclosure, the functions of the modules can be implemented in one or more software and / or hardware, and modules implementing the same function can be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described apparatus embodiment is merely illustrative, for example, the division of the units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0137] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other processing device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other processing device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 an apparatus with a function specified in one or more flow or blocks.

[0138] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0139] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0140] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0141] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory, etc. The memory is an example of computer readable media.

[0142] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0143] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0144] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0145] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific feature, structure, material or characteristic being described in connection with that embodiment or example is included in at least one embodiment or example in the specification. Illustrative representations of the above terms in the specification are not necessarily referring to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics being described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine features of different embodiments or examples and characteristics of different embodiments or examples in a manner that is not mutually contradictory.

[0146] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1. A method for off-chain processing of blockchain tasks, applied to an off-chain computing node corresponding to a blockchain node, and comprising: obtaining cached historical blockchain tasks after startup is completed, the historical blockchain tasks being generated by the blockchain node before the off-chain computing node is shut down; obtaining a current blockchain task generated by the blockchain node, the current blockchain task being generated by the blockchain node after the off-chain computing node is shut down; processing the historical blockchain tasks and the current blockchain task in parallel; wherein the current blockchain task is not necessarily processed after all the historical blockchain tasks are processed. 2.The method of claim 1, wherein the obtaining of the current blockchain task generated by the blockchain node comprises: in response to a task allocation event generated by the blockchain node performing a blockchain transaction being listened to, determining a blockchain task contained in the task allocation event as the current blockchain task in a case where the blockchain task is determined to be allocated to a blockchain member to which the blockchain node belongs. 3.The method of claim 1, wherein: Also included are: each historical blockchain task is sequentially input into a first queue according to a time sequence in which each historical blockchain task is generated, and each current blockchain task is sequentially input into a second queue according to a time sequence in which each current blockchain task is generated; the processing of the historical blockchain tasks and the current blockchain task in parallel comprises: obtaining the historical blockchain tasks and the current blockchain task from the first queue and the second queue respectively, and sequentially executing each blockchain task obtained according to an obtaining sequence. 4.The method of claim 3, wherein a main thread corresponding to the off-chain computing node comprises a first sub-thread, a second sub-thread and a third sub-thread, and the sequentially inputting of each historical blockchain task into the first queue, the sequentially inputting of each current blockchain task into the second queue, and the alternately obtaining of the historical blockchain tasks and the current blockchain task from the first queue and the second queue respectively comprises: the first sub-thread sequentially inputs each historical blockchain task into the first queue, the second sub-thread sequentially inputs each current blockchain task into the second queue, and the third sub-thread alternately obtains the historical blockchain tasks and the current blockchain task from the first queue and the second queue respectively. 5.The method of claim 3, wherein a number of the historical blockchain tasks in the first queue and a number of the current blockchain tasks in the second queue do not exceed corresponding number thresholds. 6.The method of claim 1, wherein the off-chain computing node comprises a scheduling engine and a computing engine consisting of a computing engine framework and computing units managed thereby, and the scheduling engine is configured to schedule a blockchain task to the computing engine for execution. the processing of any blockchain task in the historical blockchain tasks or the current blockchain tasks by the off-chain computing node comprises: the scheduling engine determines a target computing unit matching the any blockchain task from the computing units, and sends the any blockchain task to a target computing engine framework to which the target computing unit belongs; the target computing engine framework forwards the any blockchain task to the target computing unit in a case where the target computing unit is determined to be in an available state; and the target computing unit executes the any blockchain task. 7.The method of claim 6, wherein the determining, by the scheduling engine, the target computing unit matching the any one of the blockchain tasks from the computing units comprises: determining, by the scheduling engine, available services allowed to be invoked by the scheduling engine according to self-maintained available service information, the available services comprising computing engine frameworks and respective computing units managed by the computing engine frameworks; and determining, by the scheduling engine, the target computing unit matching the any one of the blockchain tasks from the respective computing units. 8.The method of claim 7, further comprising: obtaining, by the scheduling engine, a service change message from a service center, the service change message being used to indicate changed registered services, the registered services comprising computing engine frameworks and computing units registered to the service center; and updating, by the scheduling engine, the available service information according to the service change message, the available service information being used to indicate the computing engine frameworks and the computing units of the registered services allowed to be invoked by the scheduling engine. 9.The method of claim 8, wherein the obtaining, by the scheduling engine, the service change message from the service center comprises: initiating, by the scheduling engine, a change query request to the service center according to a preset query period, and receiving the service change message returned by the service center in a case that the service center determines that the registered services have changed; or receiving, by the scheduling engine, the service change message sent by the service center in response to the registered services having changed. 10.The method of claim 7, wherein the available service information comprises computing types of the computing units, and the determining, by the scheduling engine, the target computing unit matching the any one of the blockchain tasks from the respective computing units comprises: determining, by the scheduling engine, a target computing type corresponding to the any one of the blockchain tasks; and determining, by the scheduling engine, the target computing unit as a computing unit of the respective computing units having the target computing type. 11.The method of claim 6, wherein the determining, by the scheduling engine, the target computing unit matching the any one of the blockchain tasks from the computing units comprises: determining, by the scheduling engine, current available resource amounts of respective computing units in the off-chain computing nodes respectively; and selecting, by the scheduling engine, the target computing unit from the computing units having current available resource amounts satisfying execution conditions of the blockchain tasks, the execution conditions comprising: the current available resource amount being not less than a resource threshold, or the current available resource amount being not less than a resource amount required for executing the blockchain task. 12.The method of claim 6, wherein the executing, by the target computing unit, the any one of the blockchain tasks comprises: initiating, by the target computing unit, a data obtaining request for the any one of the blockchain tasks to a data management party, and executing the any one of the blockchain tasks according to data returned by the data management party; and / or executing, by the target computing unit, the any one of the blockchain tasks according to data carried by the any one of the blockchain tasks. 13.The method of claim 6, further comprising: ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ The scheduling engine records the obtained any blockchain task in a first task list maintained by itself and sets the task state of the any blockchain task as an unfinished state; and, in response to successfully submitting the execution result of the any blockchain task to the blockchain node, deleting the blockchain task recorded in the first task list or updating the task state of the blockchain task as a completed state; and / or, The target computing engine framework records the any blockchain task sent by the scheduling engine in a second task list maintained by itself and sets the task state of the any blockchain task as an unfinished state; and, in response to successfully returning the execution result of the any blockchain task to the scheduling engine, deleting the blockchain task recorded in the second task list or updating the task state of the blockchain task as a completed state.

14. The method of claim 1, The blockchain node and the off-chain computing node are respectively in different processes in the same node device; or, In the case where the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the computing engine framework, the blockchain node and the scheduling engine are respectively in different processes in the same node device, and the computing engine framework and the computing units managed by the computing engine framework are in the same or different computing devices outside the node device.

15. The method of claim 1, wherein the blockchain node belongs to a blockchain subnet managed by a blockchain main network, and the method further comprises: submitting the execution result of the historical blockchain task and the current blockchain task to the blockchain main network to store the execution result in the blockchain main network.

16. The method of claim 1, wherein the current blockchain task includes at least one of: a blockchain task generated by the blockchain node from the moment when the off-chain computing node stops to the moment when the current start is completed; and a blockchain task generated by the blockchain node after the current start of the off-chain computing node is completed.

17. The method of claim 1, wherein the current start of the off-chain computing node is a normal start or a restart after an abnormal stop.

18. An off-chain processing apparatus of a blockchain task, applied to an off-chain computing node corresponding to a blockchain node, the apparatus comprising: a historical task obtaining unit, configured to obtain a cached historical blockchain task generated by the blockchain node before the off-chain computing node stops after the start is completed; a current task obtaining unit, configured to obtain a current blockchain task generated by the blockchain node after the off-chain computing node stops; a parallel processing unit, configured to process the historical blockchain task and the current blockchain task in parallel; wherein the current blockchain task is not necessarily processed after all the historical blockchain tasks are processed.

19. An electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method of any one of claims 1-17 by running the executable instructions.

20. A computer readable storage medium having stored thereon computer instructions, the instructions, when executed by a processor, implementing the steps of the method of any one of claims 1-17.

Images