Off-chain processing method and apparatus for blockchain tasks

Abstract

The specification provides a method and device for off-chain processing of a blockchain task. The method is applied to a scheduling engine included in an off-chain computing node, the off-chain computing node corresponding to a blockchain node, the off-chain computing node further including a computing engine composed of a computing engine framework and a computing unit managed thereby, and the method includes: obtaining a cached historical blockchain task after startup is completed, the historical blockchain task being generated by the blockchain node before the scheduling engine is shut down; initiating a state query request for the historical blockchain task to the blockchain node; and in response to a query result returned by the blockchain node indicating that the historical blockchain task is in an incomplete state, processing the historical blockchain task.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of blockchains, and particularly relates to a method and device for off-chain processing of a blockchain task. BACKGROUND

[0002] A 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] A blockchain task generated by a blockchain network can be processed by an off-chain computing node, but the off-chain computing node may be shut down due to some reasons during the execution of the blockchain task. In related technologies, the off-chain computing node that has been started will continue to process the blockchain task being processed before the shutdown, but the above task may have been timed out and thus the processing is invalid. SUMMARY

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

[0005] According to a first aspect of one or more embodiments of the present specification, a method for off-chain processing of a blockchain task is provided, which is applied to a scheduling engine included in an off-chain computing node, the off-chain computing node corresponding to a blockchain node, the off-chain computing node further including a computing engine composed of a computing engine framework and a computing unit managed thereby, and the method comprising:

[0006] acquiring a cached historical blockchain task after startup is completed, the historical blockchain task being generated by the blockchain node before the scheduling engine is shut down;

[0007] initiating a state query request for the historical blockchain task to the blockchain node;

[0008] in response to the query result returned by the blockchain node indicating that the historical blockchain task is in an incomplete state, processing the historical blockchain task.

[0009] According to a second aspect of one or more embodiments of the present specification, a device for off-chain processing of a blockchain task is provided, which is applied to a scheduling engine included in an off-chain computing node, the off-chain computing node corresponding to a blockchain node, the off-chain computing node further including a computing engine composed of a computing engine framework and a computing unit managed thereby, and the device comprising:

[0010] a task obtaining unit, configured to obtain a cached historical blockchain task after startup is completed, the historical blockchain task being generated by the blockchain node before the scheduling engine is shut down;

[0011] a request initiating unit, configured to initiate a state query request for the historical blockchain task to the blockchain node;

[0012] a task processing unit, configured to process the historical blockchain task in response to the query result returned by the blockchain node indicating that the historical blockchain task is in an unfinished state.

[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, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to any one of the first aspect.

[0018] In the present solution, the off-chain computing node corresponding to the blockchain node comprises a scheduling engine and a computing engine composed of a computing engine framework and computing units managed thereby. The scheduling engine in the off-chain computing node can obtain a historical blockchain task generated by the blockchain node before the scheduling engine is shut down and cached after startup is completed, then initiate a state query request for the task to the blockchain node, and process the task in the case that the query result returned by the blockchain node indicates that the historical blockchain task is in an unfinished state.

[0019] It can be understood that for the historical blockchain task generated and cached before the scheduling engine is shut down, the scheduling engine does not know the current state of the task after the start is completed, in other words, the scheduling engine after the start is completed does not determine whether the historical blockchain task still needs to be processed. In this regard, since the historical blockchain task is generated by the blockchain node and issued to the off-chain computing node for processing, the scheduling engine can request the blockchain node to obtain the current state of the task. Wherein, the query result returned by the blockchain node indicates that the historical blockchain task is in an incomplete state, that is, it indicates that the scheduling engine needs to continue to process the historical blockchain task, and therefore the scheduling engine can process the task. Of course, if the above query result indicates that the historical blockchain task is in a completed state, the scheduling engine does not need to process the task. In this way, the scheduling engine can request the blockchain node as the task generation party to obtain the state of the historical blockchain task, and process the task again in the case that the latter indicates that the task needs to be processed, not only realizing the smooth recovery of the task which has not been processed before the shutdown, but also effectively avoiding the invalid processing caused by directly processing the historical blockchain task after the start, which helps to improve the task processing efficiency of the scheduling engine after the start. 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 1 FIG. 1 is a structural schematic diagram of an off-chain computing node provided by an example embodiment.

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

[0023] Figure 3 FIG. 3 is an interaction flowchart of an off-chain processing method of a blockchain task provided by an example embodiment.

[0024] Figure 4 FIG. 4 is another interaction flowchart of an off-chain processing method of a blockchain task provided by an example embodiment.

[0025] Figure 5 FIG. 5 is still another interaction flowchart of an off-chain processing method of a blockchain task provided by an example embodiment.

[0026] Figure 6 FIG. 6 is a structural schematic diagram of a device provided by an example embodiment.

[0027] Figure 7 is a block diagram of an off-chain processing device of a blockchain task provided by an example embodiment. DETAILED DESCRIPTION

[0028] In order for those skilled in the art 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 part of the embodiments of the specification, not all. Based on the embodiments in the specification, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the specification.

[0029] To solve the above problems existing in the related art, the specification proposes an off-chain processing method of a blockchain task, which ensures that only the historical blockchain tasks that need to be processed are processed by requesting the current state of the historical blockchain tasks from a blockchain node. The method is applied to a scheduling engine included in an off-chain computing node corresponding to the blockchain node, and the off-chain computing node further includes a computing engine composed of a computing engine framework and computing units managed thereby. The scheme will be described in detail below in combination with the drawings.

[0030] First, in combination with Figure 1 The structure of the off-chain computing node described in the embodiments of the specification is introduced. As shown in Figure 1 The blockchain network is composed of a plurality of blockchain nodes such as nodeA~E, and any blockchain node can correspond to a corresponding off-chain computing node. Taking nodeA as an example, the off-chain computing node A corresponding to the node can include a scheduling engine and at least one computing engine framework. For example, the scheduling engine is connected with n computing engine frameworks, such as computing engine frameworks 1~n. Among them, any computing engine framework and m computing units managed thereby constitute a computing engine. For example, computing engine 1 includes computing engine framework 1 and computing units 11~13 (m=3 at this time), computing engine 2 includes computing engine framework 2 and computing units 21~22 (m=2 at this time), …, computing engine n includes computing engine framework n and computing units n1~nm, etc. It can be seen that any off-chain computing node includes a scheduling engine, at least one computing engine framework, and at least one computing unit, and the scheduling engine can schedule each computing unit to perform a corresponding blockchain task. Among them, n and m are both integers greater than or equal to 1.

[0031] It should be noted that any chain-computing node is a computing subject composed of a corresponding scheduling engine, a computing engine framework and a computing unit at a logical level. In terms of entity devices, the components of the chain-computing node can be deployed in the same or different entity devices, and the embodiments of the present specification do not limit this. For example, the chain-computing node A can be deployed in the node device to which the corresponding blockchain node belongs, that is, the chain-computing node A and the blockchain node A are deployed in the same node device, and at this time, the scheduling engine, the computing engine framework and the computing unit contained in the chain-computing node can be corresponding functional modules running in the node device. Alternatively, the scheduling engine and each computing engine framework can be functional modules running in the node device, and each computing unit managed by the computing engine framework can run in other computing devices, so that the computing engine framework realizes remote calling of the computing unit. For another example, the chain-computing node A can also be deployed in a computing device other than the node device, and the corresponding computing engine framework and computing unit can be deployed in the node device or other node devices, which will not be described again.

[0032] It can be understood that the scheduling engine, each computing engine framework and each computing unit in the chain-computing node can be regarded as functional modules called by the blockchain node. In order to realize efficient management of each functional module, the above-mentioned each functional module can be pre-registered to a unified service center. The functional modules contained in the chain-computing nodes corresponding to each blockchain node in the blockchain network can be respectively registered to the service center. Among them, the computing unit can register its computing type, access address and other related information to the service center, and the service center can allocate a service identifier to the computing unit for identification. After the registration of any computing unit is completed, the service center can maintain the above-mentioned registration information of the computing unit. Similarly, the scheduling engine and the computing engine framework in each chain-computing node can be registered to the service center, which is called a registered service managed by the service center. The computing engine framework and the computing unit contained in any chain-computing node and registered to the service center are available services corresponding to the scheduling engine, which can be scheduled by the scheduling engine to execute the blockchain task. In other words, the scheduling engine can schedule any computing unit managed by any computing engine framework corresponding to the scheduling engine to execute the blockchain task received by the scheduling engine.

[0033] The following will be described in combination with the chain-computing method of the blockchain task shown in Figure 2 The processing process (i.e. scheduling and execution process) of the blockchain task will be described. The method is applied to the scheduling engine contained in the chain-computing node corresponding to the blockchain node, and the chain-computing node also contains the computing engine composed of the computing engine framework and the computing unit managed thereby. As shown in Figure 2 The method includes steps 202-206.

[0034] At step 202, after the startup is completed, a cached historical blockchain task is obtained, the historical blockchain task being generated by the blockchain node before the dispatch engine is shut down.

[0035] In the embodiments of the present specification, as a service constituting an off-chain computing node, the current startup of the dispatch engine can be a normal startup, or can also be a restart after abnormal shutdown (or downtime). Hereinafter, a restart after downtime is taken as an example for description. Since the dispatch engine is essentially a functional module running in a computing device (which can be the node device), the shutdown of the dispatch engine can be the stop of the functional module itself, or can also be the stop of the computing device as a whole, which is not limited in the embodiments of the present specification. Since only one dispatch engine is included in the off-chain computing node, the off-chain computing node cannot normally process blockchain tasks after the dispatch engine is shut down, so the shutdown of the dispatch engine can be regarded as the shutdown of the off-chain computing node where the dispatch engine is located, which is hereby stated.

[0036] The blockchain node in the blockchain network can generate a blockchain task that needs to be processed off-chain by the off-chain computing node, 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 dispatch engine can obtain and process it. In the embodiments of the present specification, the process of the dispatch engine processing the blockchain task includes scheduling the blockchain task to the corresponding computing unit for execution, and returning the execution result to the blockchain node. If the execution result of any blockchain task has not been successfully returned to the blockchain node (for example, the task has been obtained by the dispatch 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 dispatch engine but has not been successfully returned to the blockchain node, etc.), it can be considered that the blockchain task has not been completed.

[0037] In view of the fact that a certain time is required for processing, in order to effectively manage the blockchain tasks that have not been processed, the scheduling engine can cache the obtained blockchain tasks, for example, in the local storage space of the computing device or other storage space accessible to the scheduling engine. For example, the scheduling engine can maintain a task list for recording such tasks, and the task list is used to record the blockchain tasks obtained by the scheduling engine and for which the execution result has not been successfully returned to the blockchain node. When a blockchain task is obtained, the scheduling engine can record the task in the task list; and when the execution result of the task is returned to the blockchain node (after processing), the scheduling engine can delete the task from the task list. Alternatively, the task status of a blockchain task can be set to an unfinished state in the task list before the execution result of the task is successfully returned to the blockchain node; and the task status can be adjusted to a completed state when the execution result is successfully returned to the blockchain node. The specific form of recording the blockchain task is not limited in the embodiments of the present specification.

[0038] At the shutdown time, the scheduling engine can not have processed the blockchain tasks that have been obtained and cached. For example, at the shutdown time, there can be blockchain tasks in the task list that have not been processed, and therefore, after startup is completed, the scheduling engine can obtain such tasks from the list to continue processing.

[0039] In addition to obtaining and processing the blockchain tasks generated by the blockchain node before the scheduling engine is shut down, the scheduling engine after startup can also obtain and process the blockchain tasks generated by the blockchain node after the scheduling engine is shut down. The blockchain tasks generated by the blockchain node after the scheduling engine is shut down can include the blockchain tasks generated from the time when the scheduling engine is shut down to the time when the current startup is completed, and can also include the blockchain tasks generated after the current startup of the scheduling engine is completed. In order to distinguish the blockchain tasks that need to be obtained by the off-chain computing node, the embodiments of the present specification refer to the blockchain tasks generated before the scheduling engine is shut down as historical blockchain tasks, and refer to the blockchain tasks generated by the blockchain node after the scheduling engine is shut down as current blockchain tasks.

[0040] The scheduling engine can obtain the current blockchain task by listening to a task assignment event. For example, the blockchain node can generate a task assignment event containing the current blockchain task during execution of a blockchain transaction or a smart contract, so that the scheduling engine can obtain the current blockchain task by listening to the task assignment event. It can be understood that the process of obtaining the historical blockchain task by the scheduling engine before shutdown (the task is not yet a historical blockchain task at the time of obtaining) is not essentially different from the process of obtaining the current blockchain task after startup is completed, 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 the process of the scheduling engine for the obtained historical blockchain task and the current blockchain task does not essentially differ.

[0041] In addition, in order to avoid invalid execution of the blockchain task, the scheduling engine can determine whether it needs to process the blockchain task according to the participant information recorded in the task assignment event when listening to a task assignment event containing any blockchain task. For example, if the task assignment event contains the public key of node A, the scheduling engine can determine that node A is a participant of the blockchain task contained in the task assignment event, and therefore the scheduling engine itself (contained in the off-chain computing node corresponding to the blockchain node) needs to process the task. Therefore, the scheduling engine can record the blockchain task in the task list for subsequent processing. Of course, if the task assignment event does not contain the public key of node A, the scheduling engine can determine that node A is not a participant of the blockchain task contained in the task assignment event, and therefore can directly discard the task to avoid invalid processing of the task. Figure 1

[0042] In the case of obtaining the historical blockchain task and the current blockchain task after startup is completed, the scheduling engine can execute the blockchain tasks in various sequences. For example, in order to avoid the adverse effects of the processing sequence of each blockchain task on the execution result, the scheduling engine can process each blockchain task in the time sequence of generation or obtaining of the blockchain task, such as processing the historical blockchain task first and then processing the current blockchain task. In the case of multiple historical blockchain tasks, each historical blockchain task can be processed in the order of generation. In the case of multiple current blockchain tasks, each current blockchain task can be processed in the order of generation.

[0043] ​However, since the current blockchain task in the above processing manner needs to wait until the historical blockchain tasks are all processed, the processing of the current blockchain task can be delayed too much. In this regard, the scheduling engine can also process the historical blockchain tasks and the current blockchain tasks in parallel. For example, the historical blockchain tasks and the current blockchain tasks can be processed alternately one by one, so that the processing order of the two types of blockchain tasks is basically maintained, thereby avoiding too long waiting time of the current blockchain task. Of course, after all the historical blockchain tasks are processed, the scheduling engine only needs to process the remaining current blockchain tasks (which have been obtained but have not been processed, or which are newly generated by the blockchain node).

[0044] As mentioned above, there is no essential difference between the specific processes of the scheduling engine in processing the historical blockchain tasks and the current blockchain tasks, and the following embodiments only illustrate the process of the historical blockchain tasks.

[0045] At step 204, a state query request for the historical blockchain task is initiated to the blockchain node.

[0046] At step 206, in response to the query result returned by the blockchain node indicating that the historical blockchain task is in an unfinished state, the historical blockchain task is processed.

[0047] After obtaining the historical blockchain task, the scheduling engine can initiate a state query request to the blockchain node, and determine whether to execute the historical blockchain task according to the query result returned by the blockchain node: in response to the query result indicating that the historical blockchain task is in an unfinished state, the historical blockchain task is processed.

[0048] Of course, the above query result can also indicate that the historical blockchain task is in a completed state, that is, the blockchain node no longer needs the scheduling engine to process the historical blockchain task to obtain the execution result, and at this time the scheduling engine does not need to process the task. Therefore, the scheduling engine can respond to the query result indicating that the historical blockchain task is in a completed state, and avoid processing the historical blockchain task, thereby not only effectively avoiding the invalid processing of the task, but also saving the time cost and resource cost of processing the current blockchain task, thereby improving the overall efficiency of the off-chain computing node in processing tasks.

[0049] The blockchain node can set the historical blockchain task to a completed state in at least one of the following cases. For example, the historical blockchain task can be set with a task duration (by the smart contract or the blockchain transaction) to control the time of the task. At this time, the blockchain node can set the historical blockchain task to a completed state if the task is overdue. Accordingly, the blockchain node can control the task to be in an incomplete state if the historical blockchain task is not overdue. For another example, the blockchain node can cancel the execution of the historical blockchain task for some reasons, such as the execution of a new blockchain transaction resulting in the cancellation of the historical blockchain task, or receiving a task termination instruction issued by a user with task management authority, etc. At this time, the blockchain node can set the historical blockchain task to a completed state to terminate the processing of the task. For another example, the blockchain task can have multiple participants, and each participant can normally process the task to obtain the same execution result. In this case, any participant can terminate the processing of the task as soon as the execution result is obtained, so as to ensure that the blockchain task can be processed as soon as possible through the redundant processing of multiple participants. In this case, the blockchain node can set the historical blockchain task to a completed state if the execution result of the historical blockchain task is obtained from other related parties other than the off-chain computing node, so as to terminate the processing of the task in time.

[0050] In the present scheme, the off-chain computing node corresponding to the blockchain node includes a scheduling engine and a computing engine composed of a computing engine framework and a computing unit managed thereby. After the scheduling engine in the off-chain computing node is started, the historical blockchain task generated by the blockchain node before the scheduling engine is shut down and cached can be obtained, and then a state query request for the task is initiated to the blockchain node, and the task is processed if the query result returned by the blockchain node indicates that the historical blockchain task is in an incomplete state.

[0051] It can be understood that for the historical blockchain task generated and cached before the shutdown of the scheduling engine, the scheduling engine does not know the current state of the task after the start-up is completed, in other words, the scheduling engine after the start-up is completed does not determine whether the historical blockchain task still needs to be processed. In this regard, since the historical blockchain task is generated by the blockchain node and issued to the off-chain computing node for processing, the scheduling engine can request the blockchain node to obtain the current state of the task. Wherein, the query result returned by the blockchain node indicates that the historical blockchain task is in an incomplete state, that is, it indicates that the scheduling engine needs to continue to process the historical blockchain task, and therefore the scheduling engine can process the task. Of course, if the above query result indicates that the historical blockchain task is in a completed state, the scheduling engine does not need to process the task. In this way, the scheduling engine can request the blockchain node as the task generator to obtain the state of the historical blockchain task, and process the task again in the case that the latter indicates that the task needs to be processed, not only realizing the smooth recovery of the task that has not been processed before the shutdown, but also effectively avoiding the invalid processing caused by directly processing the historical blockchain task after the start-up, which helps to improve the task processing efficiency of the scheduling engine after the start-up.

[0052] The specific process of the scheduling engine processing the historical blockchain task will be described below in combination with multiple embodiments. First of all, it needs to be pointed out that the "historical blockchain task" in the following embodiments can be any historical blockchain task obtained as described above.

[0053] The scheduling engine in the off-chain computing node corresponds to at least one computing engine, so the scheduling engine can schedule (i.e. distribute) the historical blockchain task to the corresponding computing engine framework for execution. For example, the scheduling engine can schedule the historical blockchain task to the first computing engine matching the historical blockchain task for execution, and receive the execution result of the historical blockchain task returned by the computing engine. In this way, the scheduling engine can control the first computing engine matching the historical blockchain task to execute the task, thereby helping to realize the smooth and efficient processing of the task.

[0054] As described above, the off-chain computing node contains a scheduling engine and at least one computing unit, the scheduling engine can determine the first computing unit matching the historical blockchain task from each computing unit contained in the off-chain computing node, the computing engine framework of the first computing unit is the first computing engine framework, and the first computing engine framework and the first computing unit both belong to the first computing engine. Further, the scheduling engine can forward the historical blockchain task to the first computing unit for execution through the first computing engine framework, such as issuing the task to the first computing engine framework, and forwarding the task to the first computing unit for execution by the first computing engine framework.

[0055] For example, the scheduling engine can determine the first computing unit matching the historical blockchain task from each computing unit contained in the off-chain computing node, and manage the computing engine framework of the first computing unit, that is, the first computing engine framework. Figure 1For example, if the scheduling engine determines that the first computational unit is Figure 1 The computation unit 21 shown is the first computation engine framework, which is computation engine framework 2, and the first computation engine is computation engine 2. It is evident that when the scheduling engine determines the target computation unit, the corresponding target computation engine framework and target computation engine are also determined. At this point, the scheduling engine can distribute the aforementioned historical blockchain task to computation engine framework 2, which then forwards the task to computation unit 21 for execution. In this process, the scheduling engine determines which computation unit will execute the historical blockchain task (i.e., determines the first computation unit), and the computation engine framework forwards the task to that computation unit. Through their cooperation, accurate and efficient scheduling of historical blockchain tasks can be achieved.

[0056] As previously mentioned, the scheduling engine corresponds to available services such as the computing engine framework and computing units. Each computing unit has a corresponding computing type, which can be considered as the type of task that the computing unit can perform. In the case where any computing engine contains multiple computing units, these computing units may have the same or different computing types. Similarly, in the case where the off-chain computing node contains multiple computing units, these computing units may also have the same or different computing types. To address this, the scheduling engine can maintain a service type list, which records the computing types of each computing unit contained in the off-chain computing node. The scheduling engine can then determine the first computing unit based on this service type list. For example, the scheduling engine can first determine the target computing type of the historical blockchain task, and then, according to the service type list, determine the computing unit among the various computing units whose computing type is the target computing type as the first computing unit. The computing type and target computing type can be forwarding type, MFT (Managed File Transfer) type, privacy computing type, data query type, etc., and the embodiments in this specification do not limit this.

[0057] This method ensures that the computation type of the first computing unit executing the historical blockchain task matches the target computation type of the task, which helps to avoid execution errors and improves execution efficiency to some extent.

[0058] At any time, the service state of any of the available services can be in an available state or an unavailable state. For example, if the computing unit 11 is down (normal down or abnormal down), the computing unit cannot perform any task and can be considered to be in an unavailable state; if the computing unit 11 is performing a task, the computing unit cannot perform other tasks including the historical blockchain task at the current time, so the computing unit 11 at this time is also in an unavailable state. For another example, if the computing engine framework 2 is down, the computing engine framework cannot perform any task and can be considered to be in an unavailable state; or if the computing units 21 and 22 managed by the computing engine 2 are both in an unavailable state, there is no computing unit at the current time that the computing engine framework can call to perform a task, so the computing engine framework 2 at this time is also in an unavailable state.

[0059] 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 first computing unit in the case that the first computing unit is in an unavailable state, the task can not be successfully performed, and therefore the scheduling engine can forward the historical blockchain task to the first computing unit for execution by the first computing engine framework in the case that the first computing unit and the first computing engine framework are in an available state. Further, in the case that the first computing engine framework is down, the scheduling engine can update the service state of the computing engine framework and each of the computing units managed thereby to be in an unavailable state; or in the case that the first computing unit is down, the scheduling engine can update the service state of the computing unit to be in an unavailable state. It can be seen that the above manner takes “the first computing engine framework and the first computing unit are in an available state” as a prerequisite for “scheduling the historical blockchain task to the first computing unit by the first computing engine framework”, based on which the scheduled historical blockchain task can be successfully performed by the first computing unit as much as possible, and the scheduling and execution process is prevented from being erroneous.

[0060] In addition, it can also be used as a precondition for "determining the computing unit as the first computing unit" that "the computing unit and the computing engine framework managing the computing unit are in an available state". 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 service state maintained locally in the case of determining that the computing unit matches the historical blockchain task, and determine the computing unit as the first computing unit and the computing engine framework managing the computing unit as the first computing engine framework in the case of determining that the computing unit and the computing engine framework managing the computing unit are in an available state, and then forward the historical blockchain task to the first computing unit for execution through the first computing engine framework. This way can front the judgment process of the above-mentioned service state, which helps to further ensure the smooth execution of the blockchain task and improve the execution efficiency to a certain extent.

[0061] In the process of executing the historical blockchain task by the first computing unit, the first computing engine framework and the first computing unit may both be shut down (such as abnormal downtime or normal shutdown). In the above case, in order to ensure the smooth execution of the historical blockchain task, it is necessary to recover the task, such as selecting a second computing unit different from the first computing unit to execute the task. The task recovery process after the shutdown of the first computing engine framework and the first computing unit is described below.

[0062] In an embodiment, before receiving the execution result, if it is determined that the first computing engine framework has been shut down, the scheduling engine can schedule the historical blockchain task to a second computing engine different from the first computing engine, so as to be executed by a second computing unit in the second computing engine that matches the task. It can be understood that because each computing unit in the first computing engine framework is managed by the first computing engine framework, in the case where the first computing engine framework is shut down, the scheduling engine will not be able to invoke any computing unit in the first computing engine to execute the task, and the execution result obtained by the first computing unit executing the historical blockchain task cannot be fed back to the scheduling engine. At this time, in order to ensure the smooth execution of the task, the scheduling engine can invoke other computing engines in the off-chain computing node to execute the historical blockchain task, that is, the scheduling engine can determine a second computing unit from the computing units included in each of the other computing engines, and forward the historical blockchain task to the second computing unit for execution through the computing engine framework that manages the computing unit. Of course, the computing type of the second computing unit can also match the target computing type of the historical blockchain task, and / or the second computing unit can also be in an available state. The judgment process of the computing type and service state of the second computing unit is similar to the judgment process of the first computing unit, and will not be described here. In this way, in the case where the first computing engine framework is shut down and the first computing unit is unavailable, a second computing unit that is available can be selected to resume the historical blockchain task and continue to execute the task, so as to realize effective execution of the historical blockchain task in the abnormal (relative to the historical blockchain task) case where the first computing engine framework is shut down.

[0063] In an embodiment, the scheduling engine can perceive that the first computing engine framework is shut down in various ways. As an exemplary embodiment, after scheduling the historical blockchain task (in nature, any historical blockchain task) to the first computing engine framework, the scheduling engine can continue to schedule other blockchain tasks (such as other historical blockchain tasks in addition to the historical blockchain task or current blockchain tasks) to the computing engine framework for execution by the first computing unit or other computing units. It can be understood that if the first computing engine framework is shut down, the network connection between the scheduling engine and the computing engine framework can be disconnected, so that the scheduling engine cannot schedule the other blockchain tasks to the first computing engine framework (i.e., sending the other blockchain tasks will fail). Therefore, the scheduling engine can determine that the first computing engine framework has been shut down in the case where sending the other blockchain tasks to the first computing engine framework fails.

[0064] As another example embodiment, the scheduling engine can also acquire a service change message from the aforementioned service center, which can be used to indicate the registered services that have changed, including the computing engine framework and the computing unit registered to the service center. Further, the scheduling engine can determine that the first computing engine framework has been shut down in a case where the message indicates that the first computing engine framework has been shut down. In this way, the scheduling engine can timely perceive that the first computing engine framework has been shut down, and can start to recover the historical blockchain task as soon as possible in the abnormal case of the first computing engine framework being shut down, which helps to shorten the task delay time in this case.

[0065] The service change message can be sent by the service center to the scheduling engine in response to the first computing engine framework being shut down. For example, the scheduling engine can specify the registered services that it is interested in when it is registered to the service center, such as the scheduling engine in any off-chain computing node can specify each computing engine framework and computing unit in the off-chain computing node as the registered services that it is interested in. On this basis, the service center can actively send the scheduling engine a service change message about any registered service that the scheduling engine is interested in in a case where the registered service changes (such as being added, deleted, registered information updated, etc.). In this way, the service center can timely inform the scheduling engine after the registered service that the scheduling engine is interested in changes, so that it can update the relevant information of the service that it maintains in a timely manner. For the aforementioned first computing engine framework, the service center actively sends the scheduling engine the service change message in a case where the first computing engine framework is shut down, so that the scheduling engine can timely and accurately learn that the first 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 first computing unit.

[0066] 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 have to return a response message or only return an empty message to the scheduling engine in a case where the service state of the first computing engine framework does not change; and can return a service change message to the scheduling engine in a case where the service state changes. For example, the service center can return the service change message to the scheduling engine in a case where it determines that the first computing engine framework has been shut down, so as to inform the scheduling engine of the aforementioned change of the first computing engine framework.

[0067] In addition, each computing unit in the off-chain computing node can invoke the same preset executor to execute a blockchain task, or each computing unit of the same computing type in the off-chain computing node can invoke the same preset executor to execute a blockchain task matching the computing type. It can be seen that each computing unit is essentially a forwarding party of the blockchain task, and the forwarded blockchain task is actually executed by the preset executor. In this scenario, the blockchain task can be set with an identifier for the number of executions to avoid repeated execution of the task by the executor. For example, the scheduling engine can set a first launch identifier for the task when the historical blockchain task is obtained, and update the first launch identifier to a re-launch identifier when the execution result returned by the first computing engine fails to be received (such as a timeout, determination that the first computing engine framework is down, etc.). The first launch identifier and the re-launch identifier can be the number of dispatches (i.e., the number of distributions) of the historical blockchain task. The scheduling engine adjusts the number of dispatches of the task accordingly each time the task is dispatched, and the first launch identifier can be 1 and the re-launch identifier can be a positive integer greater than 1. Of course, the specific form of the first launch identifier and the re-launch identifier is not limited in the embodiments of the present specification, as long as they can effectively distinguish whether the current historical blockchain task is being dispatched for the first time. Further, when the historical blockchain task is set with the first launch identifier, the first computing unit can invoke the preset executor to execute the historical blockchain task, and when the historical blockchain task is set with the re-launch identifier, the first computing unit can further determine whether the preset executor is currently executing the task. If it is determined that the preset executor is currently executing the historical blockchain task, the scheduling engine does not need to repeatedly send the task to the preset executor, but can wait for the preset executor to execute the task and return the execution result of the historical blockchain task. Conversely, if it is determined that the preset executor is not currently executing the historical blockchain task, the scheduling engine can invoke the preset executor to execute the historical blockchain task.

[0068] Taking the first computing unit and the second computing unit as examples, the scheduling engine can set a first launch identifier for the historical blockchain task and schedule the historical blockchain task to the first computing unit when the scheduling engine first acquires the historical blockchain task. The first computing unit can determine that the historical blockchain task is first launched according to the first launch identifier, and in turn can directly call the preset execution party to execute the historical blockchain task. However, in the case that the first computing unit fails (for example, the first computing engine framework or the first computing unit is down), although the preset execution party can normally execute the task and obtain an execution result, the scheduling engine will fail to successfully receive the execution result returned by the first computing engine (that is, the receiving of the execution result returned by the first computing engine fails). At this time, the scheduling engine can update the first launch identifier of the historical blockchain task to a re-launch identifier, and schedule the historical blockchain task to the second computing unit. The second computing unit can further determine whether the preset execution party is currently executing the historical blockchain task when the second computing unit acquires the historical blockchain task and determines that the historical blockchain task is set with the re-launch identifier. If the preset execution party is not currently executing the historical blockchain task, it indicates that the preset execution party may not have acquired the historical blockchain task forwarded by the first computing unit, or the preset execution party may have failed in the process of executing the historical blockchain task and terminated the execution. At this time, the second computing unit can call the preset execution party to execute the historical blockchain task. Conversely, if the preset execution party is currently executing the historical blockchain task, the second computing unit does not need to repeatedly send the historical blockchain task, and only needs to wait for the preset execution party to return the execution result of the historical blockchain task.

[0069] In another embodiment, before receiving the execution result, if it is determined that the first computing unit has been shut down, the scheduling engine can schedule the historical blockchain task to a second computing unit in the first computing engine or a second computing unit in the second computing engine, so as to execute the historical blockchain task by the second computing unit. And the execution result of the historical blockchain task returned by the second computing unit through the computing engine can be received. In this way, in the case that the first computing unit is unavailable due to shutdown, the second computing unit that is available can be selected to resume the historical blockchain task and continue to execute the historical blockchain task, so as to realize effective execution of the historical blockchain task in the case of abnormality (relative to the historical blockchain task) of the shutdown of the first computing unit.

[0070] It can be understood that, in the case that the first computing unit has been shut down, the first computing unit will not be able to continue to execute the historical blockchain task. In view of the fact that the first computing engine framework and other computing engine frameworks can also manage other computing units, at this time, in order to ensure the smooth execution of the task, the scheduling engine can determine a second computing unit in the above-mentioned other computing units for executing the task. For example, the scheduling engine can determine a computing unit in the above-mentioned other computing units that is in an available state and whose computing type matches the target computing type of the historical blockchain task, and has already been taken as the second computing unit. It can be understood that, in the case that the second computing unit is managed by a computing engine framework other than the first computing engine framework, the computing engine framework that manages the second computing unit is the second computing engine framework, and the second computing engine framework and the second computing unit belong to the second computing engine.

[0071] In the above-mentioned management relationship between the computing engine framework and the computing unit, any computing engine framework and the computing unit managed by the computing engine framework can be in a relationship of a master process and a sub-process, that is, in the case that any computing engine framework is a master process, the computing unit managed by the computing engine framework can be a sub-process managed by the master process. Based on the above-mentioned management relationship between the computing engine framework and the computing unit, the first computing engine framework can timely perceive that the first computing unit has been shut down. Thus, in the case that the first computing engine framework perceives that the first computing unit has been shut down, the first computing engine framework can send an abnormal notification message about the first computing unit to the scheduling engine, so as to actively inform the scheduling engine that the first computing unit has been shut down, and timely trigger a recovery process for the historical blockchain task that the first computing unit is executing.

[0072] In addition, similar to the scheduling engine, the first computing engine framework can also maintain a task list for recording a blockchain task that is scheduled by the scheduling engine to the first computing engine framework and whose execution result has not been successfully returned to the scheduling engine. In the case that any blockchain task is obtained, the first computing engine framework can record the task in the above-mentioned task list maintained by itself; and in the case that the execution result of the task is returned to the scheduling engine (after being processed), the first computing engine framework can delete the task from the task list. Alternatively, the task state of any blockchain task can be set to an unfinished state in the above-mentioned task list before the execution result of the task is successfully returned to the scheduling engine; and in the case that the execution result is successfully returned to the scheduling engine, the task state thereof is adjusted to a completed state, and the specific form of recording a blockchain task is not limited in the embodiments of the present disclosure. Because the historical blockchain task has been sent to the first computing engine framework, the above-mentioned task list maintained by the first computing engine framework records the task.

[0073] Based on this, it can be understood that if the second computing unit belongs to the first computing engine, the scheduling engine can instruct the first computing engine framework to directly forward the historical blockchain task recorded in its task list to the second computing unit for execution without repeatedly sending the task to the first computing engine framework; if the second computing unit belongs to the second computing engine, the scheduling engine needs to send the historical blockchain task to the second computing engine framework, and the second computing engine framework forwards the task to the second computing unit for execution. Based on this, the scheduling engine can first determine the second computing unit from the first computing engine, and in the case of failure (i.e., there is no second computing unit that meets the above conditions in other computing units managed by the first computing engine framework), determine the second computing unit (as well as the second computing engine framework and the second computing engine) from other computing engines. This way can preferentially determine the computing unit managed by the first computing engine framework as the second computing unit, thereby possibly avoiding the scheduling engine from repeatedly sending the historical blockchain task to the computing engine framework, and can reduce the overall time consumption for recovering the task to a certain extent.

[0074] In an embodiment, for any blockchain task scheduled (i.e., issued) by the scheduling engine to the computing unit through the computing engine framework, the execution result of the task can be returned by the computing unit to the scheduling engine through the computing engine framework. The return process of the above execution result usually needs to consume a certain length of time, especially in the case of more tasks or larger data volume of the execution result, the return time consumption is also not negligible. Therefore, in addition to maintaining the above task list, the scheduling engine and the computing engine framework can also maintain a result list respectively. For example, the result list maintained by any computing engine framework can be used to record the execution results returned by each computing unit managed by the computing engine framework to the computing engine framework but not yet successfully returned to the scheduling engine by the blockchain task, and the result list maintained by the scheduling engine can be used to record the execution results returned by each computing engine framework corresponding to the scheduling engine to the scheduling engine but not yet uploaded to the blockchain node by the scheduling engine. It can be seen that the above task list is used to cache the corresponding blockchain task, and the above result list is used to cache the execution result of the blockchain task.

[0075] In a case that the scheduling engine obtains the historical blockchain task generated by the blockchain node, the scheduling engine can record the task in a task list maintained by the scheduling engine, determine the first computing unit and the first computing engine framework, and then assign the task to the first computing engine framework. In a case that the first computing engine framework receives the historical blockchain task assigned by the scheduling engine, the first computing engine framework can record the task in a task list maintained by the first computing engine framework, and forward the task to the first computing unit for execution. After the first computing unit completes the execution of the historical blockchain task, the first computing unit can return the execution result to the first computing engine framework. In a case that the first computing engine framework receives the execution result returned by the first computing unit, the first computing engine framework can record the execution result in a result list maintained by the first computing engine framework, and attempt to return the execution result to the scheduling engine. The first computing engine framework can return the execution results to the scheduling engine in a time sequence in which the execution results are received by the first computing engine framework, so as to avoid a long time consumption for returning the results. Until the execution result of the historical blockchain task is successfully returned to the scheduling engine (the scheduling engine can return a confirmation message to the first computing engine framework after successfully receiving the execution result), the first computing engine framework can delete the historical blockchain task recorded in the task list maintained by the first computing engine framework, and delete the execution result of the task recorded in the result list maintained by the first computing engine framework. Similarly, in a case that the scheduling engine receives the execution result returned by the first computing engine framework, the scheduling engine can record the execution result in a result list maintained by the scheduling engine, and attempt to upload the execution result to the blockchain node. The scheduling engine can upload the execution results to the blockchain node in a time sequence in which the execution results are received by the scheduling engine, so as to avoid a long time consumption for uploading the results. Alternatively, in a case that the uploading fails 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. In a case that the execution result of the historical blockchain task is successfully uploaded to the blockchain node (the blockchain node can also return a confirmation message to the scheduling engine after successfully receiving the execution result), the scheduling engine can delete the historical blockchain task recorded in the task list maintained by the scheduling engine, and delete the execution result of the task recorded in the result list maintained by the scheduling engine.

[0076] From the scheduling process of the blockchain task and the returning process of the execution result, it can be seen that for the historical blockchain task, the scheduling engine may have not 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 the 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. In the case that the execution result of the 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.

[0077] 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 first computing unit and the first computing engine framework in the manner of the foregoing embodiments, then schedule the task to the first computing unit through the first computing engine framework for execution, receive the execution result returned by the first computing unit through the first 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.

[0078] In fact, the first computing engine framework can not be affected by the shutdown of the scheduling engine during the period from the shutdown of the scheduling engine to the completion of the current start, so the first computing unit can normally execute the historical blockchain task during this period and return the execution result of the historical blockchain task to the first computing engine framework. To this end, in order to fully avoid the repeated execution of the historical blockchain task, after the start is completed, the scheduling engine can first request the first computing engine framework to obtain the execution result of the historical blockchain task. In the case where the execution result is successfully obtained, the scheduling engine can directly return the execution result to the blockchain node, completing the processing process of the task. In the case where the execution result cannot be successfully obtained, the first computing unit has not completed the execution of the task function, and at this time the scheduling engine can wait for the first computing engine framework to return the execution result, or can start scheduling the historical blockchain task again to ensure the smooth execution of the task.

[0079] So far, the execution process of the above blockchain task has been introduced. Next, the execution process of the blockchain task in the case of shutdown of the scheduling engine, the computing engine framework and the computing unit will be described in combination with the interactive flowchart shown in Figures 3-5 Please refer to the interactive flowchart of the off-chain processing method of a blockchain task shown in Figure 3 As shown in Figure 3 The method comprises steps 301-311.

[0080] Step 301, the scheduling engine starts after shutdown.

[0081] Step 302, the scheduling engine obtains the historical blockchain task cached before shutdown.

[0082] After normal shutdown or abnormal downtime, the scheduling engine can be normally started or restarted. The start can be triggered by the administrator of the off-chain computing node or the blockchain node. The specific start process can be referred to the description in the related art, which will not be described here.

[0083] After the start is completed, the scheduling engine can obtain the historical blockchain task cached before shutdown. The historical blockchain task can be recorded in the task list maintained by the scheduling engine, so the scheduling engine can obtain the historical blockchain task from the task list. It should be noted that the scheduling engine can obtain at least one historical blockchain task, and the following steps are only described for any one of the historical blockchain tasks.

[0084] Afterwards, the scheduling engine can query the execution result of the starting blockchain task in the locally maintained result list. If the execution result is queried in the result list, it can be jumped to step 311, that is, directly uploading the execution result to the blockchain node, at this time, steps 303-310 do not need to be executed. It can be understood that the execution result recorded in the result list is returned to the scheduling engine by the computing engine before the scheduling engine is shut down, and the scheduling engine has not successfully uploaded the execution result to the blockchain node before being shut down. If the execution result is not queried in the result list, it indicates that the scheduling engine has not received the execution result returned by the computing engine before the current time, at this time, it can be turned to step 303.

[0085] Step 303, the scheduling engine initiates a state query request for the historical blockchain task to the blockchain node.

[0086] Step 304, the blockchain node returns the query result to the scheduling engine in response to the state query request.

[0087] Before starting to process the blockchain task, the scheduling engine needs to determine whether it is necessary to process the task. Specifically, the scheduling engine can send a state query request for the blockchain task to the blockchain node, wherein the state query request can contain the task identification, task data and other necessary data of the task. The blockchain node can determine the current state of the task in response to the above state query request, and return the current state as the query result to the scheduling engine.

[0088] Wherein, in the case of the historical blockchain task processing timeout, the historical blockchain task being cancelled for execution by the blockchain node, and / or the blockchain node having obtained the execution result of the historical blockchain task from other related parties other than the off-chain computing node, the blockchain node can determine that the task is currently in a completed state; and in the case of the historical blockchain task processing not being timed out, the historical blockchain task not being cancelled for execution, and / or the blockchain node not having obtained the execution result of the historical blockchain task from other related parties other than the off-chain computing node, the blockchain node can determine that the task is currently in an uncompleted state.

[0089] If the query result indicates that the historical blockchain task is in a completed state, it indicates that the blockchain node no longer has the need to obtain the execution result of the task, so the scheduling engine does not need to process the task again, nor does it need to return the execution result to the blockchain node. At this time, the scheduling engine can terminate the response to the task, such as deleting it from the task list maintained by itself.

[0090] On the contrary, if the query result indicates that the historical blockchain task is in an unfinished state, it means that the blockchain node still has the demand to obtain the execution result of the task, so the scheduling engine needs to continue to process the task and return the execution result to the blockchain node. At this time, step 305 can be entered to start scheduling the task.

[0091] In step 305, the scheduling engine determines a first computing engine for the historical blockchain task.

[0092] In step 306, the scheduling engine issues the historical blockchain task to a first computing engine framework in the first computing engine.

[0093] The scheduling engine can determine a first computing unit for executing the historical blockchain task in at least one computing unit contained in the off-chain computing node. The computing type of the first computing unit can match the target computing type of the historical blockchain task, and / or the first computing unit should be in an available state. The specific process of determining the first computing unit according to the computing type and the available state has been described in the foregoing embodiments, which will not be repeated here.

[0094] In the case of determining the first computing unit, the computing engine framework managing the first computing unit is the first computing engine framework, and the first computing engine framework and the first computing unit belong to the first computing engine. The scheduling engine can determine the first computing engine framework and the first computing engine corresponding to the first computing unit according to the available service information maintained by itself, which will not be repeated here. Thereafter, the scheduling engine can issue the historical blockchain task to the first computing engine framework.

[0095] In step 307, the first computing engine framework forwards the historical blockchain task to the first computing unit in the computing engine.

[0096] After receiving the historical blockchain task issued by the scheduling engine, the first computing engine framework can record the task in the task list maintained by itself on the one hand, and forward the task to the first computing unit for execution on the other hand.

[0097] The first computing engine framework can further forward the blockchain task to the first computing unit when it is determined that the first computing unit is currently idle, so as to avoid adversely affecting the execution of the previous blockchain task by the first computing unit. Of course, in the case that the first computing unit can process multiple blockchain tasks at the same time, the first computing engine framework can further determine the current available resource amount of the first computing unit, and in response to the current available resource amount meeting the resource amount demand for executing the historical blockchain task, forward the task to the first computing unit, so as to try to ensure that the historical blockchain task is successfully executed.

[0098] Step 308, the first computing unit executes the historical blockchain task to obtain an execution result.

[0099] The first computing unit can execute the historical blockchain task using task data contained in the blockchain task and / or task data obtained from other related parties. Corresponding to the computing type of the first computing unit, the historical blockchain task can be a specific mode such as task forwarding, privacy computing, large file transmission, data query, etc., which will not be repeated here.

[0100] Step 309, the first computing unit returns the execution result to the first computing engine framework.

[0101] Step 310, the first computing engine framework returns the execution result to the scheduling engine.

[0102] In the case of completing the execution of the historical blockchain task, the first computing unit can return the corresponding execution result to the first computing engine framework. Accordingly, in the case of receiving the execution result returned by the first computing unit, the first computing engine framework can record the execution result in the result list it maintains, and can also try to return the execution result to the scheduling engine.

[0103] Wherein, the first computing engine framework can return each execution result to the scheduling engine in the order of the time when it receives each execution result, so as to avoid too long time consumption of result returning. Until the execution result of the historical blockchain task is successfully returned to the scheduling engine (the scheduling engine can return an acknowledgement message to the computing engine framework after successfully receiving the execution result), the first computing engine framework can delete the historical blockchain task recorded in the task list it maintains, and delete the execution result of the task recorded in the result list it maintains.

[0104] Step 311, the scheduling engine uploads the execution result to the blockchain node.

[0105] Similarly, in the case of receiving the execution result returned by the first computing engine framework, the scheduling engine can record the execution result in the result list it maintains, and try to upload the execution result to the blockchain node.

[0106] The scheduling engine can sequentially upload the execution results to the blockchain node in the order of the time when the scheduling engine receives each execution result, so as to avoid long time consumption of result uploading. Alternatively, in the case where uploading fails 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. In the case where the execution result of the historical blockchain task is successfully uploaded to the blockchain node (the blockchain node can return a confirmation message to the scheduling engine after successfully receiving the execution result), the scheduling engine can delete the historical blockchain task recorded in the task list maintained by the scheduling engine and delete the execution result of the task recorded in the result list maintained by the scheduling engine.

[0107] In this way, the scheduling engine can request the blockchain node as the task generator to obtain the status of the historical blockchain task, and process the task again in the case where the blockchain node indicates that the task needs to be processed. This not only realizes smooth recovery of the task that has not been processed before shutdown, but also effectively avoids invalid processing caused by directly processing the historical blockchain task after startup, and helps to improve the task processing efficiency of the scheduling engine after startup.

[0108] In fact, in addition to obtaining and processing the historical blockchain task, the scheduling engine after startup can also obtain and process a current blockchain task generated by the blockchain node after the scheduling engine is shut down. In fact, there is no essential difference between the specific processing processes of the historical blockchain task and the current blockchain task by the scheduling engine. In the process of processing any blockchain task, the first computing engine framework corresponding to the task may be shut down (which can be regarded as shutdown of the first computing engine corresponding to the first computing engine framework), and the first computing unit executing the task may also be shut down. In the above two types of shutdown scenarios, the scheduling engine, the computing engine framework and the computing unit can cooperate with each other to realize recovery of the task, so as to successfully execute the task and return the execution result to the blockchain node. The following will be described in combination with Figure 4 and Figure 5 respectively.

[0109] Please refer to the interaction flowchart of another off-chain processing method of a blockchain task shown in Figure 4 As shown in Figure 4 , the method comprises steps 401-406. The first computing unit executing the blockchain task can be Figure 1 the computing unit 11 shown in FIG. 1, so that the first computing engine framework is Figure 1 the computing engine framework 1 shown in FIG. 1, and the first computing engine is Figure 1 the computing engine 1 shown in FIG. 1.

[0110] In step 401, the computing engine framework 1 is shut down.

[0111] As mentioned above, in the case that the execution result of the blockchain task performed by the computing unit 11 has not been successfully returned to the scheduling engine, the computing engine framework 1 can be shut down, such as being normally shut down by an administrator or being crashed due to a fault. In this case, the computing engine framework 1 can be regarded as the computing engine 1 being shut down.

[0112] In the case that the computing engine framework 1 is shut down, each computing unit (i.e., the computing units 11-13) managed by the computing engine framework 1 cannot continue to work normally, and thus the computing unit 11 stops performing the blockchain task. It should be noted that, in the case that the blockchain task is not performed completely, the computing unit 1 stopping performing the task will result in the intermediate data in the process of performing the task being lost.

[0113] In step 402, the scheduling engine senses that the computing engine 1 is shut down.

[0114] The scheduling engine can determine that the computing engine framework 1 is shut down in the case that the scheduling engine fails to send other blockchain tasks to the computing engine framework 1, or the scheduling engine can obtain a service change message from the service center and determine that the first computing engine framework is shut down according to the message. The registered services include the computing engine frameworks and the computing units registered to the service center. The service change message can be sent by the service center in response to the first computing engine framework being shut down, or the scheduling engine can request and obtain the service change message from the service center according to a preset query period. The specific process of determining that the computing engine framework 1 is shut down in the above manner can be referred to the description of the foregoing embodiments, which will not be described here.

[0115] In step 403, the scheduling engine determines a second computing engine.

[0116] In the case that the computing engine 1 is determined to be shut down, the scheduling engine can determine the second computing engine from other computing engines included in the off-chain computing node. Specifically, the second computing unit can be determined from each computing unit managed by a computing engine framework other than the first computing engine framework. Similar to the first computing unit, the computing type of the second computing unit can also match the target computing type of the blockchain task, and / or the second computing unit is in an available state at the current time.

[0117] In the case that the second computing unit is determined, the computing engine framework managing the second computing unit is the second computing engine framework, and the second computing engine framework and the second computing unit belong to the second computing engine. It is assumed that the second computing unit determined in the above manner is the computing unit 21 shown in FIG. 2, the second computing engine framework is the computing engine framework 2, and the second computing engine is the computing engine 2. Figure 1

[0118] ​Step 404, the scheduling engine schedules the blockchain task to the second computing engine.

[0119] Step 405, the second computing engine executes the blockchain task.

[0120] Step 406, the second computing engine returns the execution result of the blockchain task to the scheduling engine.

[0121] After determining the second computing unit, the scheduling engine can schedule the blockchain task to the second computing engine for execution and receive the execution result returned by the latter. For example, the scheduling engine can forward the blockchain task to the computing unit 21 for execution through the computing engine framework 2; correspondingly, the computing unit 21 can return the execution result to the scheduling engine through the computing engine framework 2, thereby completing the scheduling and execution process of the task. The specific process of steps 404-406 can refer to steps 306-310 of Figure 3 , which will not be described here again.

[0122] In addition, the scheduling engine can return the execution result returned by the second computing engine to the blockchain node, thereby realizing the continuous execution of the task and the normal uploading of the execution result in the case that the first computing engine framework is shut down abnormally during the execution of the blockchain task by the first computing unit.

[0123] Please refer to the interaction flowchart of another off-chain processing method of a blockchain task shown in Figure 5 . As shown in Figure 5 , the method comprises steps 501-507, the first computing unit executing the blockchain task can be any computing unit managed by the computing engine framework 1 shown in Figure 1 , thereby the first computing engine framework is the computing engine framework 1 shown in Figure 1 , and the first computing engine is the computing engine 1 shown in Figure 1 .

[0124] Step 501, the first computing unit is shut down.

[0125] As described before, in the case that the execution result of the blockchain task executed by the first computing unit has not been successfully returned to the scheduling engine, the first computing unit can be shut down, such as being normally closed by the administrator or being shut down due to failure. In the case that the first computing unit is shut down, it will stop executing the blockchain task.

[0126] Step 502, the computing engine framework 1 senses that the first computing unit has been shut down.

[0127] Step 503, the computing engine framework 1 notifies the scheduling engine that the first computing engine has been shut down.

[0128] In the case where the computing engine framework 1 is the master process, the computing unit managed by the computing engine framework 1 can be the respective sub-processes managed by the master process. Based on the above management relationship, the computing engine framework 1 can timely perceive that the first computing unit has been shut down. Thus, in the case where the computing engine framework 1 perceives that the first computing unit has been shut down, the computing engine framework 1 can send an abnormal notification message about the first computing unit to the scheduling engine to actively inform the scheduling engine that the first computing unit has been shut down, and timely trigger the recovery process of the blockchain task being executed by the first computing unit.

[0129] Step 504, the scheduling engine determines a second computing unit.

[0130] In the case where the computing engine 1 has been shut down, the scheduling engine can determine the second computing unit from other computing units contained in the off-chain computing node. For example, the second computing unit can be first determined from other computing units managed by the computing engine framework 1 except the first computing unit, and if the determination fails (i.e., there is no second computing unit matching the blockchain task in the above other computing units), the second computing unit can be determined from the respective computing units managed by other computing engine frameworks. The specific process can be referred to the foregoing embodiments, which will not be described here.

[0131] Step 505, the scheduling engine schedules the blockchain task to the second computing unit.

[0132] Step 506, the second computing unit executes the blockchain task.

[0133] Step 507, the second computing unit returns the execution result of the blockchain task to the scheduling engine.

[0134] In the case where the second computing unit is determined, the scheduling engine can schedule the blockchain task to the second computing unit for execution and obtain the execution result returned thereby. It can be understood that the second computing unit determined by the above method can belong to the computing engine 1 (i.e., managed by the computing engine framework 1) or other computing engines (i.e., managed by other computing engine frameworks), and the scheduling engine can use different ways to schedule the task. Hereinafter, the first computing unit is taken as the computing unit 11 for example.

[0135] In the case where the second computing unit belongs to the computing engine 1, it is assumed that the second computing unit is the computing unit 13. At this time, the scheduling engine can issue the blockchain task to the computing engine framework 1, and the computing engine framework 1 forwards the blockchain task to the computing unit 13 for execution. Alternatively, because the computing engine framework 1 forwards the blockchain task to the computing unit 11 in advance, the scheduling engine can send a notification message for the task to the computing engine framework 1 to trigger the computing engine framework 1 to forward the message to the computing unit 13 for execution, based on the fact that the task is recorded in the task list maintained by the computing engine framework 1. Further, the computing unit 13 can return the execution result to the scheduling engine through the computing engine framework 1.

[0136] In the case where the second computing unit belongs to another computing engine, it is assumed that the second computing unit is the computing unit 21 belonging to the computing engine 2. At this time, the scheduling engine can issue the blockchain task to the computing engine framework 2, and the computing engine framework 2 forwards the blockchain task to the computing unit 21 for execution. Further, the computing unit 21 can return the execution result to the scheduling engine through the computing engine framework 2.

[0137] In addition, the scheduling engine can return the execution result returned by the second computing engine to the blockchain node, so that in the case where the first computing unit stops during the execution of the blockchain task, the scheduling engine can continue the execution of the task and upload the execution result normally.

[0138] Figure 6 is a schematic structural diagram of an apparatus provided by an example embodiment. Please refer to Figure 6 At the hardware level, the apparatus includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610, and can also include other hardware required by a 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 610 into the memory 608 by the processor 602 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 a logic device 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.

[0139] As shown in Figure 7 , Figure 7 is a block diagram of an off-chain processing apparatus of a blockchain task provided by an example embodiment of the present specification. The apparatus can be applied to, for example, Figure 6The device shown in the device is used to implement the technical solutions of the present specification. The device is applied to a scheduling engine included in an off-chain computing node corresponding to a blockchain node, the off-chain computing node further including a computing engine composed of a computing engine framework and a computing unit managed by the computing engine framework, and the device includes:

[0140] A historical task acquisition unit 701 is configured to acquire a cached historical blockchain task after startup is completed, the historical blockchain task being generated by the blockchain node before the scheduling engine is shut down;

[0141] A state query unit 702 is configured to initiate a state query request for the historical blockchain task to the blockchain node;

[0142] A historical task processing unit 703 is configured to, in response to a query result returned by the blockchain node indicating that the historical blockchain task is in an unfinished state, process the historical blockchain task.

[0143] Optionally, the historical task acquisition unit 701 is further configured to:

[0144] acquire a historical blockchain task cached by the scheduling engine in the task list before the scheduling engine is shut down, the task list being used to record a blockchain task acquired by the scheduling engine and for which an execution result has not been successfully returned to the blockchain node.

[0145] Optionally, the device further includes:

[0146] A current task acquisition unit 704 is configured to acquire a current blockchain task generated by the blockchain node, the current blockchain task being generated by the blockchain node after the scheduling engine is shut down;

[0147] A current task processing unit 705 is configured to process the current blockchain task and return a corresponding execution result to the blockchain node.

[0148] Optionally, the historical task processing unit 703 and the current task processing unit 705 are further configured to:

[0149] process the historical blockchain task and the current blockchain task in parallel; or,

[0150] process the current blockchain task after the historical blockchain task is processed.

[0151] Optionally, the historical task processing unit 703 is further configured to:

[0152] schedule the historical blockchain task to a first computing engine matched with the historical blockchain task for execution;

[0153] receive the execution result of the historical blockchain task returned by the first computing engine.

[0154] Optionally, the historical task processing unit 703 is further configured to:

[0155] determine, from each computing unit contained in the off-chain computing node, a first computing unit matched to the historical blockchain task and a first computing engine framework to which the first computing unit belongs, the first computing unit and the first computing engine framework belonging to the first computing engine;

[0156] forward, by the first computing engine framework, the historical blockchain task to the first computing unit for execution.

[0157] Optionally, the method further comprises:

[0158] the first scheduling unit 706 is configured to, before receiving the execution result, if it is determined that the first computing engine framework has been shut down, schedule the historical blockchain task to a second computing engine different from the first computing engine, so that a second computing unit matched to the historical blockchain task in the second computing engine executes the historical blockchain task;

[0159] the first returning unit 707 is configured to receive the execution result of the historical blockchain task returned by the second computing engine.

[0160] Optionally, the first scheduling unit 706 is further configured to:

[0161] send other blockchain tasks to the first computing engine framework; or

[0162] a service change message obtained from the service center indicates that the first computing engine framework has been shut down, the service change message being used to indicate registered services after a change, the registered services including computing engine frameworks and computing units registered to the service center.

[0163] Optionally, the first scheduling unit 706 is further configured to:

[0164] receive a service change message sent by the service center in response to the first computing engine framework having been shut down; or

[0165] initiate a change query request to the service center according to a preset query period, and receive the service change message returned by the service center in a case where it is determined that the first computing engine framework has been shut down.

[0166] Optionally,

[0167] The task identification unit 708 is further configured to set a first identification for the historical blockchain task if the historical blockchain task is obtained, and update the first identification to a re-identification if the execution result returned by the first computing engine is not received.

[0168] The historical task processing unit 703 is further configured to: if the historical blockchain task is set with the first identification, invoke the preset execution party to execute the historical blockchain task by the first computing unit; and if the historical blockchain task is set with the re-identification, invoke the preset execution party to execute the historical blockchain task by the first computing unit if it is determined that the preset execution party is not currently executing the historical blockchain task.

[0169] Optionally, the apparatus further comprises:

[0170] The result waiting unit 709 is configured to wait for the preset execution party to return the execution result of the historical blockchain task by the first computing unit if it is determined that the preset execution party is currently executing the historical blockchain task.

[0171] Optionally, the apparatus further comprises:

[0172] The second scheduling unit 710 is configured to, during processing of the historical blockchain task, if it is determined that the first computing unit has been shut down before the execution result is received, schedule the historical blockchain task to a second computing unit in the first computing engine or a second computing unit in the second computing engine, so as to execute the historical blockchain task by the second computing unit.

[0173] The second returning unit 711 is configured to receive the execution result of the historical blockchain task returned by the second computing unit through the computing engine.

[0174] Optionally, the second scheduling unit 710 is further configured to:

[0175] Determine that the first computing unit has been shut down according to an exception notification message sent by the first computing engine framework.

[0176] Optionally, the scheduling engine maintains a service state of an available service corresponding to the scheduling engine, and the available service comprises the computing engine framework and the computing unit, and the apparatus further comprises:

[0177] The task forwarding unit 712 is configured to, if the first computing unit and the first computing engine framework are in an available state, forward the historical blockchain task to the first computing unit for execution by the first computing engine framework.

[0178] The state updating unit 713 is configured to update a service state of the first computing engine framework and each computing unit managed by the first computing engine framework to an unavailable state in a case where the first computing engine framework has been stopped, or update a service state of the first computing unit to an unavailable state in a case where the first computing unit has been stopped.

[0179] Optionally, the result list maintained by the scheduling engine is used to record an execution result that has not been successfully returned to the blockchain node, and the historical task processing unit 703 is further configured to:

[0180] return the execution result to the blockchain node in a case where the execution result of the historical blockchain task is recorded in the result list; or

[0181] schedule the historical blockchain task to a computing unit in the computing engine for execution in a case where the execution result of the historical blockchain task is not recorded in the result list, and record the execution result returned by the computing engine to the result list and return the execution result to the blockchain node.

[0182] Optionally, the scheduling engine further comprises:

[0183] a result deleting unit 714 configured to delete the execution result recorded in the result list in a case where it is determined that the execution result has been successfully returned to the blockchain node.

[0184] Optionally, the scheduling engine further comprises:

[0185] an avoiding processing unit 715 configured to avoid processing the historical blockchain task in response to a query result returned by the blockchain node indicating that the historical blockchain task is in a completed state.

[0186] Optionally, the blockchain node sets the historical blockchain task to the completed state in at least one of the following cases:

[0187] the historical blockchain task processing times out;

[0188] the historical blockchain task is cancelled for execution by the blockchain node;

[0189] the blockchain node has obtained an execution result of the historical blockchain task from another related party other than the off-chain computing node.

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

[0191] 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) (e.g., 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 PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is 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.

[0192] 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.

[0193] The systems, apparatuses, modules or units illustrated by the above 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 embodiments can be personal computers, laptop computers, 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.

[0194] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above description of the embodiments of the present specification is provided as an example only and is not intended to be limiting. For example, the steps recited in the examples or flow charts can include more, fewer, or different steps than those described. The order in which the steps are presented is merely one example and is not intended to be limiting. The steps can be performed in an order different than presented, or performed in parallel, or in a different order, for example in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment. The terms "comprise", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Exclusion of such elements is only present if it is expressly stated that these elements are excluded. For example, use of the terms "first", "second", or the like does not denote any order or importance, but rather the terms are used to distinguish one element from another.

[0195] For ease of description, the above apparatuses are described in various modules with different functions. Of course, when implementing one or more of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiments are only illustrative, for example, the division of the units is only a logical function division, and in actual implementation, another division mode can be used, 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 interface, device or unit, and can be electrical, mechanical or other forms.

[0196] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (system) and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product of manufacture that includes an article of manufacture that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The term "means for" can include, by way of example, various components such as one or more Figure 1 The term "means for" can include, by way of example, various components such as one or more

[0197] 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.

[0198] 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.

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

[0200] 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. The memory is an example of computer-readable media.

[0201] 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.

[0202] 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.

[0203] 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.

[0204] 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 use of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the particular feature, structure, material or characteristic being described is included in at least one embodiment or example of the specification. Illustrative descriptions of the above terms do not necessarily refer to the same embodiment or example in this specification. Furthermore, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples. Moreover, the skilled person can combine and combine the features of different embodiments or examples and characteristics of different embodiments or examples, without contradiction.

[0205] 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. An off-chain processing method for blockchain tasks, applied to a scheduling engine contained in an off-chain computing node, the off-chain computing node corresponding to a blockchain node, the off-chain computing node containing one scheduling engine and at least one computing engine, wherein each computing engine consists of a computing engine framework and at least one computing unit managed by it, the method comprising: After startup is complete, retrieve the historical blockchain tasks cached locally on the off-chain computing node. These historical blockchain tasks were generated by the blockchain node before the scheduling engine stopped. Initiate a status query request for the historical blockchain task to the blockchain node; In response to the query result returned by the blockchain node indicating that the historical blockchain task is in an incomplete state, the historical blockchain task is processed.

2. The method according to claim 1, wherein obtaining the historical blockchain tasks cached locally on the off-chain computing node after startup includes: The scheduling engine retrieves historical blockchain tasks cached in its own maintained task list before shutdown. The task list records blockchain tasks retrieved by the scheduling engine whose execution results have not yet been successfully returned to the blockchain node.

3. The method according to claim 1, further comprising: Obtain the current blockchain task generated by the blockchain node, which is generated by the blockchain node after the scheduling engine stops; Process the current blockchain task and return the corresponding execution result to the blockchain node.

4. The method according to claim 3, processing the historical blockchain task and the current blockchain task, includes: The historical blockchain tasks and the current blockchain tasks are processed in parallel. or, After the historical blockchain tasks have been processed, the current blockchain task is processed.

5. The method according to claim 1, processing the historical blockchain task, comprising: The historical blockchain task is scheduled to be executed by the first computing engine that matches the historical blockchain task; Receive the execution results of the historical blockchain task returned by the first computing engine.

6. The method according to claim 5, wherein scheduling the historical blockchain task to a first computing engine matching the historical blockchain task for execution comprises: From the various computing units contained in the off-chain computing node, determine the first computing unit that matches the historical blockchain task and its corresponding first computing engine framework. The first computing unit and the first computing engine framework belong to the first computing engine. The historical blockchain tasks are forwarded to the first computing unit for execution through the first computing engine framework.

7. The method according to claim 5, further comprising: If it is determined that the first computing engine framework has stopped before the execution result is received, the historical blockchain task is scheduled to a second computing engine that is different from the first computing engine, so that the historical blockchain task is executed by the second computing unit in the second computing engine that matches the historical blockchain task. Receive the execution results of the historical blockchain task returned by the second computing engine.

8. The method according to claim 7, wherein determining that the first computing engine framework has stopped includes: Sending other blockchain tasks to the first computing engine framework failed; or, The service change message obtained from the service center indicates that the first computing engine framework has been shut down. The service change message is used to indicate the registered services after the change. The registered services include the computing engine framework and computing units that have been registered with the service center.

9. The method according to claim 8, wherein obtaining a service change message from the service center includes: Receive service change messages sent by the service center in response to the downtime of the first computing engine framework; or, The system initiates a change query request to the service center according to a preset query cycle, and receives the service change message returned by the service center when it determines that the first computing engine framework has been shut down.

10. The method according to claim 6, Also includes: If the historical blockchain task is obtained, a first-launch identifier is set for the historical blockchain task; and if the execution result returned by the first computing engine fails, the first-launch identifier is updated to a resend identifier. The first computing unit executes the historical blockchain task, including: when the historical blockchain task is set with the first-release identifier, the first computing unit calls a preset executor to execute the historical blockchain task. Furthermore, if the historical blockchain task is set with the resend flag, and the first computing unit determines that the preset executor is not currently executing the historical blockchain task, then it calls the preset executor to execute the historical blockchain task.

11. The method of claim 10, further comprising: If the first computing unit determines that the preset executor is currently executing the historical blockchain task, it waits for the preset executor to return the execution result of the historical blockchain task.

12. The method according to claim 5, further comprising, in the process of processing the historical blockchain task: If it is determined that the first computing unit has stopped before the execution result is received, the historical blockchain task is scheduled to the second computing unit in the first computing engine or the second computing unit in the second computing engine, so that the second computing unit can execute the historical blockchain task. Receive the execution result of the historical blockchain task returned by the second computing unit through its computing engine.

13. The method according to claim 12, wherein determining that the first computing unit has stopped includes: The first computing unit has been shut down based on the exception notification message sent by the first computing engine framework.

14. The method according to any one of claims 6-13, wherein the scheduling engine maintains the service status of its corresponding available services, the available services including the computing engine framework and the computing units. The step of forwarding the historical blockchain task to the first computing unit for execution through the first computing engine framework includes: When the first computing unit and the first computing engine framework are available, the historical blockchain task is forwarded to the first computing unit for execution through the first computing engine framework; The method further includes: if the first computing engine framework is down, updating the service status of the first computing engine framework and each computing unit it manages to an unavailable state; or, if the first computing unit is down, updating the service status of the first computing unit to an unavailable state.

15. The method according to claim 1, wherein the result list maintained by the scheduling engine is used to record execution results that have not yet been successfully returned to the blockchain node, and the processing of the historical blockchain tasks includes: If the execution results of the historical blockchain tasks are recorded in the result list, the execution results are returned to the blockchain node; or, If the execution result of the historical blockchain task is not recorded in the result list, the historical blockchain task is scheduled to be executed by a computing unit in the computing engine, and the execution result returned by the computing engine is recorded in the result list and returned to the blockchain node.

16. The method of claim 15, further comprising: If it is determined that the execution result has been successfully returned to the blockchain node, the execution result recorded in the result list is deleted.

17. The method according to claim 1, further comprising: In response to the query result returned by the blockchain node, the historical blockchain task is in a completed state, and the historical blockchain task is avoided from being processed.

18. The method of claim 17, wherein the blockchain node sets the historical blockchain task to the completed state in at least one of the following cases: The historical blockchain task processing timed out; The historical blockchain task was canceled by the blockchain node. The blockchain node has obtained the execution results of the historical blockchain task from other relevant parties besides the off-chain computing node.

19. The method according to claim 1, wherein the current startup of the off-chain computing node is a normal startup or a restart after an abnormal shutdown.

20. An off-chain processing apparatus for blockchain tasks, applied to a scheduling engine contained in an off-chain computing node, the off-chain computing node corresponding to a blockchain node, the off-chain computing node containing one of the scheduling engines and at least one computing engine, wherein each computing engine consists of a computing engine framework and at least one computing unit managed by it, the apparatus comprising: The historical task acquisition unit is used to acquire historical blockchain tasks cached locally on the off-chain computing node after startup is completed. The historical blockchain tasks are generated by the blockchain node before the scheduling engine stops. The status query unit is used to initiate a status query request for the historical blockchain task to the blockchain node. The historical task processing unit is used to process the historical blockchain task in response to a query result returned by the blockchain node indicating that the historical blockchain task is in an incomplete state.

21. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-19 by executing the executable instructions.

22. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-19.

Images