Service update method and device

Abstract

This specification provides a service update method and device. The method is applied to an off-chain computing node corresponding to a blockchain node, wherein the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the scheduling engine. The scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. The method includes: obtaining a service change message from a service center, wherein the service change message is used to indicate a registered service after a change, wherein the registered service includes a computing engine framework and computing units registered with the service center; and updating locally maintained available service information based on the service change message, wherein the available service information is used to indicate available services in the registered service that are allowed to be called by the scheduling engine.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly, to a service update method and device. Background Art

[0002] Blockchain is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, and cryptographically guaranteed to be tamper-proof and unforgeable.

[0003] Blockchain tasks generated by a blockchain network can be processed by off-chain computing nodes by calling pre-registered service components. In related technologies, off-chain computing nodes use configuration files to record the service components they can call. If a service component changes, the off-chain computing node needs to reload the updated configuration file in order to call the changed service component. Typically, off-chain computing nodes reload the updated configuration file by shutting down and restarting.

[0004] Obviously, if the off-chain computing node is processing a blockchain task when reloading the configuration file, shutting down and restarting it will forcibly interrupt the blockchain task in progress, and may even cause the loss of data related to the task. Under this method, not only is the execution efficiency of blockchain tasks low, but the stability of the off-chain computing node in executing blockchain tasks also needs to be improved. Summary of the Invention

[0005] The object of the present invention is to provide a service updating method and device.

[0006] According to a first aspect of one or more embodiments of this specification, a service update method is proposed, which is applied to an off-chain computing node corresponding to a blockchain node, wherein the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the computing engine framework, and the scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. The method includes:

[0007] Obtaining a service change message from a service center, wherein the service change message is used to indicate a registered service after the change, wherein the registered service includes a computing engine framework and a computing unit registered with the service center;

[0008] The locally maintained available service information is updated according to the service change message, where the available service information is used to indicate the available services in the registered services that are allowed to be called by the scheduling engine.

[0009] According to a second aspect of one or more embodiments of this specification, a service update device is provided, which is applied to an off-chain computing node corresponding to a blockchain node, wherein the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the computing engine framework, and the scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. The device includes:

[0010] A message acquisition unit, configured to acquire a service change message from a service center, wherein the service change message indicates a registered service after the change, wherein the registered service includes a computing engine framework and a computing unit registered with the service center;

[0011] An information updating unit is configured to update locally maintained available service information according to the service change message, wherein the available service information is used to indicate available services in the registered services that are allowed to be called by the scheduling engine.

[0012] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, including:

[0013] processor;

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

[0015] The processor implements the method as described in any one of the first aspects by running the executable instructions.

[0016] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any one of the first aspects are implemented.

[0017] In this solution, the off-chain computing nodes corresponding to blockchain nodes include a scheduling engine and a computing engine composed of a computing engine framework and the computing units it manages. The scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. The off-chain computing nodes obtain service change messages from the service center, indicating the changes to registered services, and update the locally maintained available service information based on the messages. The available service information indicates the available services among the registered services that are allowed to be called by the scheduling engine.

[0018] It is understood that after the above update is completed, the available services indicated by the updated available service information are also the available services that have changed. Based on the updated available service information, the scheduling engine can determine the computing engine corresponding to the blockchain task to be used to execute the blockchain task. For example, if the above update corresponds to the addition of a new computing unit, the newly added computing unit can be immediately used to execute the blockchain task after the above update is completed. Obviously, the above update process does not require the off-chain computing node to reload the configuration file, nor does it require the off-chain computing node to be shut down and restarted. This method can achieve real-time, online updates of available services. Therefore, this method reduces the adverse impact on the currently processed blockchain task, not only helping to ensure the execution efficiency of the blockchain task, but also to a certain extent improving the stability of the off-chain computing node in processing the blockchain task. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 This is a structural diagram of an off-chain computing node provided by an exemplary embodiment.

[0021] Figure 2 This is a flowchart of an off-chain processing method for a blockchain task provided by an exemplary embodiment.

[0022] Figure 3 It is a structural diagram of a device provided by an exemplary embodiment.

[0023] Figure 4 This is a block diagram of an off-chain processing device for blockchain tasks provided by an exemplary embodiment. DETAILED DESCRIPTION

[0024] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0025] To address the aforementioned issues in related technologies, this specification proposes a service update method that updates locally maintained available service information by acquiring service change messages, thereby enabling real-time, online updates of available services corresponding to off-chain computing nodes. This method is applied to off-chain computing nodes corresponding to blockchain nodes. These off-chain computing nodes include a scheduling engine and a computing engine composed of a computing engine framework and the computing units it manages. The scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. This solution is described in detail below with reference to the accompanying figures.

[0026] The off-chain computing node described in the embodiment of this specification can be composed of multiple functional modules. Figure 1 The structure of the off-chain computing node described in the embodiments of this specification is introduced. Figure 1 As shown, the blockchain network is composed of multiple blockchain nodes such as nodeA~E. 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 this node can include a scheduling engine and at least one computing engine framework. For example, the scheduling engine is connected to n computing engine frameworks, such as computing engine frameworks 1~n. Among them, any computing engine framework and the m computing units it manages constitute a computing engine. For example, computing engine 1 includes computing engine framework 1 and computing units 11~13 (in this case m=3), computing engine 2 includes computing engine framework 2 and computing units 21~22 (in this case m=2), ..., computing engine n includes computing engine framework n and computing units n1~nm, etc. It can be seen that any off-chain computing node contains a scheduling engine, at least one computing engine framework and at least one computing unit. The scheduling engine can schedule each computing unit to perform corresponding blockchain tasks respectively. Among them, the above n and m are both integers greater than or equal to 1.

[0027] The off-chain computing node corresponding to any blockchain node can be a computing entity composed of a corresponding scheduling engine, computing engine framework, and computing unit at the logical level. In terms of physical devices, the various components of the off-chain computing node can be deployed in the same or different physical devices, and the embodiments of this specification are not limited to this. For example, off-chain computing node A can be deployed in the node device to which the corresponding blockchain node belongs, that is, off-chain computing node A and blockchain node A are deployed in the same node device. In this case, the scheduling engine, computing engine framework, and computing unit contained in the off-chain computing node can be the corresponding functional modules running in the node device. Alternatively, the above-mentioned scheduling engine and each computing engine framework can run in the functional module of the node device, while the computing units managed by each computing engine framework can run in other computing devices, so that the computing engine framework can realize remote calls to the computing units. For another example, off-chain computing node A can also be deployed in a computing device other than the node device, while the corresponding computing engine framework and computing unit can be deployed in the node device or other node devices, which will not be repeated.

[0028] It is understood that the scheduling engine, various computing engine frameworks, and various computing units in off-chain computing nodes can all be considered functional modules invoked by blockchain nodes. To achieve efficient management of these functional modules, these modules can be pre-registered with a unified service center. The functional modules contained in each off-chain computing node corresponding to each blockchain node in the blockchain network can be registered with the service center. Computing units can register their computing type, access address, and other related information with the service center, and the service center can assign service identifiers to the computing units for easy identification. After any computing unit is registered, the service center can maintain the registration information for that computing unit. Similarly, the scheduling engine and computing engine framework in each off-chain computing node can be registered with the service center, referred to as registered services managed by the service center. The computing engine framework and computing units contained in any off-chain computing node that have been registered with the service center are available services corresponding to the scheduling engine and can be scheduled by the scheduling engine to execute blockchain tasks. In other words, the scheduling engine can dispatch received blockchain tasks to any computing unit managed by any of its corresponding computing engine frameworks for execution.

[0029] The following combination Figure 2 The service update method shown in the figure illustrates the update process of available service information. This method is used for the off-chain computing node corresponding to the blockchain node. The off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and the computing units managed by it. The scheduling engine is used to schedule the blockchain tasks generated by the blockchain node to the computing engine for execution. Figure 2As shown, the method includes steps 202-204.

[0030] Step 202: Obtain a service change message from the service center. The service change message is used to indicate a registered service after the change. The registered service includes a computing engine framework and a computing unit registered with the service center.

[0031] As previously mentioned, the registered services of the off-chain computing nodes may include the computing engine framework and computing units registered with the service center. In the event of a change to the registered services, the service center may generate a corresponding service change message based on the changed registered services and provide the message to the off-chain computing nodes.

[0032] In off-chain computing nodes, in addition to the computing engine framework and computing units already registered with the service center, the scheduling engine can also be registered with the service center to achieve standardized management of various functional modules. In other words, the scheduling engine can also be a registered service registered with the service center. For example, after the scheduling engine is started, the scheduling engine can initiate a service registration request to the service center to register the scheduling engine with the service registration center. In response to the service registration request initiated by the scheduling engine, the service center can record the scheduling engine's registration information and the computing node identifier of the off-chain computing node it represents to distinguish it from other off-chain computing nodes. Alternatively, the service center can only record the scheduling engine's registration information and manage it as a corresponding off-chain computing node. In this case, the off-chain computing node described in this solution is merely a logical concept, and the service center actually only manages each scheduling engine—that is, for any off-chain computing node, the service center does not distinguish between the off-chain computing node and the scheduling engine it contains. Based on this, an off-chain computing node can receive service change messages from the service center through the scheduling engine if the scheduling engine has already registered with the service center.

[0033] After any registered service is registered, the registration information recorded by the service center may include the service name, service type (such as the computing type of the computing unit, the computing type of each computing unit managed by the computing engine framework, etc.), service status (available or unavailable), and / or service interface information (IP (Internet Protocol Address), interface (Port), etc.). Based on this registration information, the service center can manage each registered service, and if any registered service changes, the service center can update its registration information accordingly.

[0034] In one embodiment, when the service center determines that any registered service has changed, it can generate the service change message based on the registration information of the registered service. For example, all or part of the registration information can be recorded in the service change message to accurately inform other registered services (such as the scheduling engine) of the specific circumstances of the registered service that has changed. Considering that the above changes usually cause changes in the registration information of the registered service, the service center can generate the service change message based on the updated registration information after completing the update of the above registration information. The specific process will not be repeated here.

[0035] A change to any registered service described in the embodiments of this specification may include at least one of the following scenarios: For example, the change may include the addition of any registered service, i.e., the registration of any computing engine framework or any computing unit to the service center. If a computing engine framework is added, the computing units managed by that computing engine framework may also be added accordingly. Another example is the deletion of any registered service, i.e., the termination of registration of any registered service with the service center and its removal from the service center. If a computing engine framework is deleted, the computing units managed by that computing engine framework may also be deleted. Another example is a change in the service status of any registered service, such as a switch between an available and an unavailable state. It is understood that any registered service can only be called by the scheduling engine if it is in an available state. Another example is a change in the call information of any registered service, such as a change in its access path, or a change in the service name, service object type, etc., which will not be further described. When at least one of the above changes occurs to at least one registered service, the service center may generate a corresponding service change message based on the change.

[0036] In one embodiment, the service center can send the service change message to the off-chain computing node in various ways. For example, the service center can send the service change message to the off-chain computing node in response to a change in the registered service. In this manner, the service center proactively sends the service change message to the scheduling engine when a registered service changes, allowing the scheduling engine to promptly and accurately be notified of the change. This helps the scheduling engine promptly update available service information and effectively reduces response delays after a service change.

[0037] For another example, the scheduling engine can also initiate a change query request to the service center according to a preset query cycle. If no registered services have changed, the service center may not need to return a response message to the scheduling engine, or may only return an empty message. However, if a registered service has changed, the service center may return a service change message to the scheduling engine. For example, if the service center determines that a registered service has changed, it may generate a service change message based on the change and return it to the scheduling engine as a response to the change query request, notifying the scheduling engine of the change.

[0038] In one embodiment, the service center may maintain a first type list, which is used to record the service types of the services that each scheduling engine registered with the service center is interested in. The service change message may be sent by the service center to the scheduling engine when the first type list records the service type of the computing engine that has changed. For example, when registering with the service center, the scheduling engine may specify the service type of the registered service that it is interested in, such as the computing type of the computing unit that it is interested in. The computing type described in the embodiment of this specification may be a forwarding type, an MFT (Managed File Transfer, large file transfer) type, a privacy computing type, a data query type, etc., and the embodiment of this specification is not limited to this. Accordingly, after the scheduling engine completes registration, the service center may record the correspondence between the above service types and the service name or identifier of the scheduling engine in the first type list it maintains. Thereafter, when it is determined that a registered service that meets the above service type has changed, the service center may generate the service change message and actively send it to the scheduling engine or return the message to the scheduling engine in response to the change query request initiated by the scheduling engine.

[0039] It is understandable that for a certain type of registered service, when any registered service changes, the service center can specifically notify the various scheduling engines of the type of interest, while other scheduling engines that do not pay attention to this type will not receive the service change message. For any scheduling engine, the service center can specifically notify the change when a specific type of registered service that the scheduling engine pays attention to changes, and the service center will not notify the scheduling engine even if other types of service change messages that the scheduling engine does not pay attention to change. It can be seen that this method can achieve type-level and user-level targeted reminders for changes in registered services through the function of paying attention to specific types of registered services, which helps to improve the accuracy of change notifications.

[0040] Of course, when registering with the service center, the scheduling engine can also specify the registered services it is interested in. For example, the scheduling engine in any off-chain compute node can specify each compute engine framework and compute unit in that off-chain compute node as the registered services it is interested in. In this case, the service center can notify the scheduling engine when any of these registered services changes. This allows for targeted service-level notifications of changes to registered services, making notifications and alerts more accurate.

[0041] Typically, for services that haven't yet been registered with the service center, the scheduling engine may not know their specific types or services, making it impossible for the scheduling engine to pre-determine the type of service or service of interest to the service center. To address this, when a new service of a specific type is registered with the service center, the service center can generate a corresponding service addition message and send it to all or some of the registered services, so that the registered services can invoke the new service based on the message.

[0042] Step S204: updating the locally maintained available service information according to the service change message, wherein the available service information is used to indicate the available services in the registered services that are allowed to be called by the scheduling engine.

[0043] Upon receiving the service change message, the off-chain computing node can update the locally maintained available service information based on the message. Specifically, if the available service information is maintained locally by the scheduling engine in the off-chain computing node, the scheduling engine can implement the above update operation. In addition, since the off-chain computing node typically maintains the available service information of all available services among the registered services that are allowed to be called by the scheduling engine, when performing the above update of the available service information, it can first determine the registered service corresponding to the service change message and then update the available service information of the registered service in a targeted manner. This will not be further described.

[0044] In the embodiments described in this specification, the available service information for any of the available services may include the aforementioned registration information, and may also include the current load information for the service, such as the current number of processing tasks, the total amount of callable resources, the current amount of available resources, etc. In other words, the available service information for any registered service maintained by the off-chain computing node may include the service name, service type, service status, service interface information, and / or current load information for the service. Based on the available service information, the scheduling engine in the off-chain computing node can determine the various available services that it can call.

[0045] In this solution, the off-chain computing nodes corresponding to blockchain nodes include a scheduling engine and a computing engine composed of a computing engine framework and the computing units it manages. The scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. The off-chain computing nodes obtain service change messages from the service center, indicating the changes to registered services, and update the locally maintained available service information based on the messages. The available service information indicates the available services among the registered services that are allowed to be called by the scheduling engine.

[0046] It is understood that after the above update is completed, the available services indicated by the updated available service information are also the available services that have changed. Based on the updated available service information, the scheduling engine can determine the computing engine corresponding to the blockchain task to be used to execute the blockchain task. For example, if the above update corresponds to the addition of a new computing unit, the newly added computing unit can be immediately used to execute the blockchain task after the above update is completed. Obviously, the above update process does not require the off-chain computing node to reload the configuration file, nor does it require the off-chain computing node to be shut down and restarted. This method can achieve real-time, online updates of available services. Therefore, this method reduces the adverse impact on the currently processed blockchain task, not only helping to ensure the execution efficiency of the blockchain task, but also to a certain extent improving the stability of the off-chain computing node in processing the blockchain task.

[0047] As mentioned above, the available services of the off-chain computing node include available computing engine frameworks or available computing units, both of which may change, so the service change message obtained by the off-chain computing node may correspond to the available computing engine framework or the available computing unit. Because the available computing engine framework manages at least one available computing unit, in both cases, the scheduling engine needs to update the available service information of the available computing engine framework and the available computing unit involved in the change. For example, when the service change message indicates that the registered service that has changed is an available computing unit, the scheduling engine can update the available service information of the available computing unit that has changed, and update the available service information of the available computing engine framework that manages the available computing unit. At this time, when the available computing unit (such as any computing unit in any off-chain computing node) changes, it is necessary not only to update the available service information of the computing unit in a targeted manner, but also to update the available service information of the corresponding computing engine framework. For another example, when the service change message indicates that the registered service that has changed is an available computing engine framework, the scheduling engine can update the available service information of the available computing engine framework and each available computing unit it manages separately. At this time, if the available computing engine framework (such as any computing engine framework in any off-chain computing node) changes, it is necessary not only to update the available service information of the computing engine framework, but also to update the available service information of each computing unit it manages accordingly.

[0048] by Figure 1 For example, the scheduling engine maintains the available service information of each computing engine framework and each computing unit in computing engines 1 to n, wherein the available service information of each computing engine framework constitutes an available framework information set, and the available service information of each computing unit constitutes an available unit information set. If computing unit 14 is newly added to computing engine 1, the scheduling engine can add the computing unit identifier of computing unit 14 to the available service information of computing engine framework 1, and add the available service information of computing unit 14 to the available unit information set. If a computing engine framework n+1 is newly added to the off-chain computing node, and the computing engine framework manages computing units n1 to n3, the scheduling engine can add the available service information of computing engine framework n+1 to the available framework information set (which records the computing unit identifiers of computing units n1 to n3), and add the available service information of computing units n1 to n3 to the available unit information set. If the computing engine framework 2 is deleted from the off-chain computing node, the scheduling engine can delete the available service information of the computing engine framework 2 (which records the computing unit identification of the computing units 21-22) in the available framework information set, and delete the available service information of the computing units 21-22 in the available unit information set.

[0049] Blockchain nodes in a blockchain network can generate blockchain tasks that require off-chain processing by off-chain computing nodes. For example, blockchain nodes can generate blockchain tasks by executing smart contracts or blockchain transactions. After the available service information is updated, the off-chain computing nodes can obtain the blockchain tasks generated by the blockchain transactions executed by the blockchain nodes and then process the blockchain tasks based on the updated available service information. This processing process is described below with reference to various embodiments.

[0050] In one embodiment, the process of the scheduling engine processing a blockchain task may include scheduling the blockchain task to a 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 (e.g., the task has been acquired by the scheduling engine but has not yet been scheduled to the corresponding computing unit, the task has been scheduled to the corresponding computing unit for execution but has not yet completed, or the computing unit has returned the execution result to the scheduling engine but has not yet been successfully returned to the blockchain node by the scheduling engine), the blockchain task may be considered to have not been processed.

[0051] Given that the processing process takes a certain amount of time, in order to effectively manage unfinished blockchain tasks, the scheduling engine can cache acquired blockchain tasks, such as in the computing device's local storage space or other storage space accessible to the scheduling engine. For example, the scheduling engine can maintain a task list to record such tasks. This task list also records blockchain tasks acquired by the scheduling engine whose execution results have not yet been successfully returned to the blockchain node. Upon acquiring any blockchain task, the scheduling engine may record the task in the task list; upon completing the task (after processing and returning the execution result of the task to the blockchain node), the scheduling engine may delete the task from the task list. Alternatively, before the execution result of any blockchain task is successfully returned to the blockchain node, the task status of the task may be set to "incomplete" in the task list; upon successfully returning the execution result to the blockchain node, the task status may be adjusted to "completed." The embodiments of this specification do not limit the specific method for recording blockchain tasks.

[0052] When the above-mentioned blockchain task is obtained, the scheduling engine may be shut down for some reason, such as being shut down normally by the user or being shut down due to an abnormal situation. After that, the scheduling engine can complete the startup. Accordingly, this startup of the scheduling engine can be a normal startup, or it can also be a restart after an abnormal shutdown (or downtime). Among them, since the above-mentioned scheduling engine is essentially a functional module running in a computing device, the shutdown of the above-mentioned scheduling engine can be the cessation of operation of the functional module itself, or it can also be the cessation of operation of the computing device as a whole. The embodiments of this specification are not limited to this. Given that the off-chain computing node only contains one scheduling engine, the off-chain computing node will not be able to process blockchain tasks normally after the scheduling engine is shut down. Therefore, the shutdown of the scheduling engine can be regarded as the shutdown of the off-chain computing node where it is located. This is hereby explained.

[0053] During downtime, the scheduling engine may not have completed processing the blockchain tasks that it has already retrieved and cached. For example, during downtime, there may be unprocessed blockchain tasks in the task list. Therefore, after the startup is complete, the scheduling engine can retrieve such tasks from the list and continue processing them based on the updated available service information.

[0054] After startup is complete, the scheduling engine can not only obtain and process the aforementioned blockchain tasks generated by the blockchain node before the scheduling engine was shut down, but also obtain and process blockchain tasks generated by the blockchain node after the scheduling engine was shut down. The blockchain tasks generated by the blockchain node after the scheduling engine was shut down can include blockchain tasks generated between the time the scheduling engine was shut down and the time the current startup was completed, or they can include blockchain tasks generated after the scheduling engine was shut down. To distinguish the blockchain tasks that need to be obtained by the off-chain computing nodes, the embodiments of this specification refer to the aforementioned shutdown time as historical blockchain tasks for blockchain tasks generated before the scheduling engine was shut down, and as current blockchain tasks for blockchain tasks generated after the scheduling engine was shut down.

[0055] Among them, the scheduling engine can obtain the current blockchain task by monitoring the task assignment event. For example, in the process of executing a blockchain transaction or a smart contract, a blockchain node can generate a task assignment event containing the current blockchain task, so that the scheduling engine can obtain the current blockchain task by monitoring the above-mentioned task assignment event. It can be understood that the process of the scheduling engine obtaining the historical blockchain task before the shutdown (the task is not a historical blockchain task when the historical blockchain task is obtained) is not essentially different from the process of obtaining the current blockchain task after the startup is completed, and will not be repeated. In fact, the historical blockchain tasks and the current blockchain tasks described in the embodiments of this specification differ only in the timing of generation and the method of acquisition. For the acquired historical blockchain tasks and current blockchain tasks, there is no essential difference in the process of the scheduling engine processing them.

[0056] In addition, in order to avoid invalid execution of blockchain tasks, when the scheduling engine monitors a task assignment event containing any blockchain task, it can determine whether it needs to process the blockchain task based on the participant information recorded in the task assignment event. Figure 1 For example, in the case where the public key of the participating node is included in the task assignment event, if the task assignment event includes the public key of nodeA, the scheduling engine can determine that nodeA is a participant of the blockchain task included in the task assignment event, so the scheduling engine itself (included in the off-chain computing node corresponding to the blockchain node) needs to process the task; thus, the scheduling engine can record the blockchain task to the task list so that it can be processed later according to the updated available service information. Of course, if the task assignment event does not include the public key of nodeA, the scheduling engine can determine that nodeA is not a participant of the blockchain task included in the task assignment event, so it can directly discard the task, thereby avoiding invalid processing of the task.

[0057] It is understandable that for historical blockchain tasks generated and cached before the scheduling engine is shut down, the scheduling engine does not know the current status of the task after the startup is completed. In other words, the scheduling engine that has completed startup is not sure whether the historical blockchain task still needs to be processed. In this regard, given that the historical blockchain task is generated by the blockchain node and sent to the off-chain computing node for processing, the scheduling engine can request the blockchain node to obtain the current status of the task, and determine whether the historical blockchain task needs to be executed based on 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. 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 only if the latter indicates that the task needs to be processed. This not only achieves the smooth recovery of tasks that have not been processed before the shutdown, but also avoids the invalid processing that may result from directly processing the historical blockchain task after startup, which helps to improve the task processing efficiency of the scheduling engine after startup.

[0058] Of course, the query result may also indicate that the historical blockchain task is in a completed state, meaning that the blockchain node no longer needs the scheduling engine to process the historical blockchain task to obtain the execution result. In this case, the scheduling engine does not need to process the task. Therefore, in response to the query result indicating that the historical blockchain task is in a completed state, the scheduling engine can avoid processing the historical blockchain task. This not only effectively avoids ineffective processing of the task, but also saves the time and resource costs of processing the current blockchain task, thereby improving the overall efficiency of the off-chain computing node in processing tasks.

[0059] After obtaining the above-mentioned historical blockchain tasks and current blockchain tasks, the scheduling engine can process these blockchain tasks in a variety of ways. For example, the scheduling engine can process each blockchain task in the order in which each blockchain task was generated. For example, the scheduling engine can process each historical blockchain task in the order of their generation time. After processing all historical blockchain tasks, the scheduling engine can then process each current blockchain task in the order of their generation time. In this way, the earlier the blockchain task is generated, the higher the processing order (i.e., the earlier it is processed), thereby minimizing processing errors caused by the inconsistency between the processing order of blockchain tasks and the generation order.

[0060] As another example, to avoid excessive waiting times for later-generated current blockchain tasks, the scheduling engine can also process historical blockchain tasks and current blockchain tasks in parallel. For example, historical blockchain tasks and current blockchain tasks can be acquired alternately, and each blockchain task can be executed sequentially in the order in which they were acquired. This approach can shorten the time between when off-chain computing nodes acquire a current blockchain task and when they begin processing it, effectively reducing the waiting time for the current blockchain task. This solution can improve the execution efficiency of current blockchain tasks and help prevent the accumulation of current blockchain tasks generated after a system outage from being processed in a timely manner.

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

[0062] Among them, the off-chain computing node includes a scheduling engine and at least one computing unit. The scheduling engine can determine the target computing unit that matches the target blockchain task from the various computing units contained in the off-chain computing node. The computing engine framework that manages the target computing unit is the target computing engine framework, and the target computing engine framework and the target computing unit both belong to the target computing engine. It can be seen that when the scheduling engine determines the target computing unit, the corresponding target computing engine framework and target computing engine are also determined. Furthermore, the scheduling engine can send the target blockchain task to the target computing engine framework, and the target computing engine framework, when determining that the target computing unit is in an available state, forwards the target blockchain task to the target computing unit so that it can execute the task.

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

[0064] Any computing unit has a corresponding computing type, which can be regarded as the type of task that the computing unit can perform. Among them, when any computing engine contains multiple computing units, the computing types of these computing units may be the same or different. Similarly, when the off-chain computing node contains multiple computing units, the computing types of these computing units may also be the same or different. In order to further ensure that the target computing unit smoothly executes the target blockchain task and improve the execution efficiency of the task, the scheduling engine can determine the target computing unit based on the computing type. For example, similar to the service center, the scheduling engine can maintain a second type list, which is used to record the computing types of each computing unit contained in the off-chain computing node. Based on this, the scheduling engine can first determine the target computing type corresponding to the target blockchain task, and then query the target computing unit corresponding to the target computing type in the second type list.

[0065] Among them, if there is only one computing unit corresponding to the target computing type in the second type list, then the computing unit can be used as the target computing unit. If there are multiple computing units corresponding to the target computing type in the second type list, the target computing unit can be selected from these computing units (hereinafter referred to as candidate computing units). For example, considering that the target computing unit needs to consume a certain amount of resources to execute the target blockchain task, in order to maximize the success rate of the target computing unit in executing the target blockchain task, the scheduling engine can select the target computing unit based on the resource amount of the computing unit. Specifically, the scheduling engine can determine the current available resource amount of each candidate computing unit respectively, and select the target computing unit from the computing units whose current available resource amount meets the execution conditions of the blockchain task. Among them, the execution conditions may include: the current available resource amount is not less than the resource threshold, or the current available resource amount is not less than the resource amount required to execute the blockchain task, etc. In this way, the available resources during the execution process can be determined before the target blockchain task is executed, thereby helping the target computing unit to execute the task smoothly and efficiently.

[0066] In one embodiment, the execution result of the target blockchain task can also be returned to the blockchain node. For example, the target computing unit can forward the execution result of the blockchain task to the scheduling engine via the target computing engine framework, and the scheduling engine can then submit the execution result to the blockchain node. The scheduling engine can do this by sending a consensus-free blockchain message to the blockchain node, and including the execution result in the message.

[0067] In one embodiment, the scheduling engine may record the target blockchain task in its own task list, determine the target computing unit and target computing engine framework, and then issue the task to the target computing engine framework. Upon receiving the target blockchain task issued by the scheduling engine, the target computing engine framework may record the task in its own task list and forward the task to the target computing unit for execution. After the target computing unit completes execution of the target blockchain task, it may return the execution result to the target computing engine framework. Upon receiving the execution result returned by the target computing unit, the target computing engine framework may record it in its own result list and attempt to return the execution result to the scheduling engine. The target computing engine framework may return each execution result to the scheduling engine in the order in which it received them, to avoid excessively long result return times. Once the execution result of the target blockchain task is successfully returned to the scheduling engine (the scheduling engine may return a confirmation message to the computing engine framework upon successful receipt of the execution result), the target computing engine framework may delete the historical blockchain task from its own task list and the execution result of the task from its own result list.

[0068] Similarly, when the scheduling engine receives the execution result returned by the target computing engine framework, it can record the execution result in the result list maintained by itself and attempt to upload the execution result to the blockchain node. Among them, the scheduling engine can upload each execution result to the blockchain node in the order in which it receives each execution result to avoid taking too long to upload the result. Alternatively, if the upload fails for some reason, the scheduling engine can wait for a period of time and try to upload again until the upload is successful. When the execution result of the target 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 target blockchain task recorded in the task list maintained by itself and delete the execution result of the task recorded in the result list maintained by itself.

[0069] Upon obtaining the execution result of the target blockchain task, the off-chain computing node can return it to the blockchain node so that the blockchain node can use the result. Specifically, if the blockchain transaction that generated the target blockchain task is used to instruct the blockchain node to invoke the workflow defined in the smart contract, the execution result can be used by the blockchain node to advance the workflow. For example, the workflow corresponding to the blockchain transaction contains multiple task nodes, and there are dependencies between each task node. The workflow can be advanced based on these dependencies. The target blockchain task can correspond to any of these task nodes, and after receiving the execution result of the target blockchain task, the blockchain node can advance the workflow to execute another blockchain task that depends on any of the task nodes. In this way, the blockchain node can execute the blockchain tasks corresponding to each task node in sequence according to the preset steps corresponding to the workflow until the blockchain transaction is completed.

[0070] In one embodiment, the blockchain nodes described in this specification may belong to a blockchain subnet managed by the blockchain mainnet. Figure 1 As shown in the figure, if some blockchain nodes nodeA~E in a certain blockchain network (denoted as net1, not shown in the figure) have a need for small-scale interaction, a new blockchain network (denoted as net2, i.e. Figure 1 Assume that net1 contains 12 nodes, nodes A through L. The user corresponding to at least one of nodes A through E, or the administrator of net1, can initiate a subnet generation transaction within net1. Each node in net1, nodes A through L, can then execute the transaction. During the transaction, nodes A through E can determine that they are participants in net2 based on the transaction content, while other nodes, nodes F through L, can determine that they are not participants in net2. Based on this, nodes A through E can establish net2 among themselves using the consensus link of net1, while nodes F through L do not participate in this subnet formation process. Net2, established in this manner, can be managed by net1. In this case, net1 becomes the blockchain mainnet, and net2 becomes the blockchain subnet.

[0071] In this scenario, the off-chain computing node corresponding to blockchain node A in the blockchain subnet, upon obtaining the execution results of the historical blockchain task and / or the current blockchain task, can submit these execution results to the blockchain mainnet to store these execution results on the blockchain mainnet. In this way, the blockchain mainnet used to manage the blockchain subnet can also store the execution results of the blockchain tasks corresponding to the blockchain nodes in the blockchain subnet, thereby relying on the blockchain mainnet's data management capabilities to achieve the storage of these execution results, which helps to improve the storage security of this data.

[0072] Figure 3 This is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 3 At the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, a memory 308, and a non-volatile memory 310. Of course, it may also include hardware required for other services. One or more embodiments of this specification can be implemented based on software, such as the processor 302 reading the corresponding computer program from the non-volatile memory 310 into the memory 308 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0073] like Figure 4 As shown, Figure 4 This is a block diagram of a service update device provided in accordance with an exemplary embodiment of this specification. The device is applied to an off-chain computing node corresponding to a blockchain node. The off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and the computing units it manages. The scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution. The device includes:

[0074] A message acquisition unit 401 is configured to acquire a service change message from a service center, wherein the service change message indicates a registered service after the change, wherein the registered service includes a computing engine framework and a computing unit registered with the service center;

[0075] The information updating unit 402 is configured to update locally maintained available service information according to the service change message, wherein the available service information is used to indicate available services in the registered services that are allowed to be called by the scheduling engine.

[0076] Optionally, the message acquiring unit 401 is further configured to:

[0077] receiving a service change message sent by a service center in response to a change in the registered service; or

[0078] Initiate a change query request to the service center according to a preset query cycle, and receive the service change message returned by the service center when it is determined that the registered service has changed.

[0079] Optionally, the message acquiring unit 401 is further configured to:

[0080] The scheduling engine obtains a service change message from the service center;

[0081] The first type list maintained by the service center is used to record the service types of the services concerned by the scheduling engine, and the service change message is sent by the service center to the scheduling engine when the first type list records the service type of the computing engine that has changed.

[0082] Optionally, the service change message includes a new service message, and the specific service type of the new service indicated by the new service message is not recorded in the first type list.

[0083] Optionally, the available service includes an available computing engine framework or an available computing unit, and the information updating unit 402 is further configured to:

[0084] In a case where the service change message indicates that the registered service that has changed is an available computing unit, the scheduling engine updates the available service information of the available computing unit that has changed and the available computing engine framework that manages the available computing unit respectively;

[0085] In a case where the service change message indicates that the registered service that has changed is an available computing engine framework, the scheduling engine updates the available service information of the available computing engine framework and each available computing unit managed by the framework.

[0086] Optionally, also include:

[0087] A task acquisition unit 403 is used to acquire a blockchain task generated by the blockchain node executing a blockchain transaction;

[0088] The task processing unit 404 is configured to process the blockchain task according to the updated available service information.

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

[0090] After the scheduling engine is started, it obtains cached historical blockchain tasks, where the historical blockchain tasks are generated by the blockchain node before the scheduling engine is shut down; and / or,

[0091] The scheduling engine obtains a current blockchain task generated by the blockchain node, where the current blockchain task is generated by the blockchain node after the scheduling engine is shut down.

[0092] Optionally, when the scheduling engine obtains the historical blockchain task and the current blockchain task, the task processing unit 404 is further configured to:

[0093] Process the historical blockchain task and the current blockchain task in parallel; or,

[0094] After the historical blockchain task is processed, the current blockchain task is processed.

[0095] Optionally, the task processing unit 404 is further configured to:

[0096] Initiate a status query request for the historical blockchain task to the blockchain node;

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

[0098] Optionally, the task processing unit 404 is further configured to:

[0099] The scheduling engine determines a target computing unit that matches any blockchain task and its target computing engine framework from the available services;

[0100] The target computing engine framework forwards any blockchain task to the target computing unit when determining that the target computing unit is in an idle state;

[0101] The target computing unit executes any of the blockchain tasks.

[0102] Optionally, the second type list maintained by the scheduling engine records the computing type of each computing unit included in the off-chain computing node, and the task processing unit 404 is further used to:

[0103] The scheduling engine determines the target computing type corresponding to any blockchain task;

[0104] The scheduling engine searches the second type list for a target computing unit corresponding to the target computing type.

[0105] Optionally, this startup of the off-chain computing node is a normal startup or a restart after an abnormal shutdown.

[0106] Optionally, the target computing unit for processing the blockchain task is managed by a target computing engine framework, and the device further includes:

[0107] A result forwarding unit 405, wherein the target computing unit forwards the execution result of the blockchain task to the scheduling engine through the target computing engine framework;

[0108] The result submission unit 406 is configured to submit the execution result to the blockchain node by the scheduling engine.

[0109] Optionally, the result submitting unit 406 is further configured to:

[0110] Upon receiving the execution result forwarded by the target computing engine framework, the scheduling engine saves the execution result in a first result list maintained by itself; and upon determining that the execution result is successfully submitted to the blockchain node, the scheduling engine deletes the execution result saved in the first result list; and / or,

[0111] Upon receiving the execution result sent by the target computing unit, the target computing engine framework saves the execution result in a second result list maintained by itself; and upon determining that the execution result is successfully forwarded to the scheduling engine, the target computing engine framework deletes the execution result saved in the second result list.

[0112] Optionally, the blockchain node belongs to a blockchain subnet managed by a blockchain mainnet, and the device further includes:

[0113] The result evidence storage unit 407 is used to submit the execution result of the blockchain task to the blockchain main network to store the execution result on the blockchain main network.

[0114] Optionally, the blockchain transaction is used to instruct the blockchain node to call a workflow defined in a smart contract, and the execution result of the blockchain task is used to advance the workflow.

[0115] Optional,

[0116] The message acquisition unit 401 is further configured to: when the scheduling engine has been registered with the service center, obtain a service change message from the service center by the scheduling engine;

[0117] The apparatus further includes a scheduling registration unit 408, configured to, when the scheduling engine is started, initiate a service registration request from the scheduling engine to the service center, so as to register the scheduling engine with the service registration center.

[0118] Optionally, any registered service changes, including at least one of the following:

[0119] Adding any of the registered services, deleting any of the registered services, changing the service status of any of the registered services, and changing the call information of any of the registered services.

[0120] Optionally, the available service information of any available service includes at least one of the following:

[0121] Service name, service type, service status, service call information, and current load information.

[0122] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, 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. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0123] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers 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. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0124] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a server system. Of course, the present invention does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0125] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0126] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0127] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks 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 device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0128] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

[0131] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0132] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be 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 tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0133] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0134] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0135] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0136] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A service update method, applied to an off-chain computing node corresponding to a blockchain node, wherein the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the computing engine framework, and the scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution, the method comprising: Obtaining a service change message from a service center, wherein the service change message is used to indicate a registered service after the change, wherein the registered service includes a computing engine framework and a computing unit registered with the service center; The locally maintained available service information is updated according to the service change message, where the available service information is used to indicate the available services in the registered services that are allowed to be called by the scheduling engine.

2. The method according to claim 1, wherein obtaining a service change message from a service center comprises: receiving a service change message sent by a service center in response to a change in the registered service; or, Initiate a change query request to the service center according to a preset query cycle, and receive the service change message returned by the service center when it is determined that the registered service has changed.

3. The method according to claim 1, wherein obtaining a service change message from a service center comprises: The scheduling engine obtains a service change message from the service center; The first type list maintained by the service center is used to record the service types of the services concerned by the scheduling engine, and the service change message is sent by the service center to the scheduling engine when the first type list records the service type of the computing engine that has changed. 4 . The method according to claim 3 , wherein the service change message comprises a new service message, and the specific service type of the new service indicated in the new service message is not recorded in the first type list.

5. The method according to claim 1, wherein the available service comprises an available computing engine framework or an available computing unit, and the updating of locally maintained available service information according to the service change message comprises: In a case where the service change message indicates that the registered service that has changed is an available computing unit, the scheduling engine updates the available service information of the available computing unit that has changed and the available computing engine framework that manages the available computing unit respectively; In a case where the service change message indicates that the registered service that has changed is an available computing engine framework, the scheduling engine updates the available service information of the available computing engine framework and each available computing unit managed by the framework.

6. The method according to claim 1, further comprising: Obtaining a blockchain task generated by executing a blockchain transaction on the blockchain node; Process the blockchain task according to the updated available service information.

7. The method according to claim 6, wherein obtaining the blockchain task generated by the blockchain node executing the blockchain transaction comprises: After the scheduling engine is started, it obtains the cached historical blockchain tasks, where the historical blockchain tasks are generated by the blockchain node before the scheduling engine is shut down; and / or, The scheduling engine obtains a current blockchain task generated by the blockchain node, where the current blockchain task is generated by the blockchain node after the scheduling engine is shut down.

8. The method according to claim 7, wherein, when the scheduling engine obtains the historical blockchain task and the current blockchain task, processing the blockchain task comprises: Processing the historical blockchain task and the current blockchain task in parallel; or, After the historical blockchain task is processed, the current blockchain task is processed.

9. The method according to claim 7, processing the historical blockchain task, comprising: 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 unfinished state, the historical blockchain task is processed.

10. The method according to claim 7, processing any one of the historical blockchain tasks or the current blockchain tasks, comprising: The scheduling engine determines a target computing unit that matches any blockchain task and its target computing engine framework from the available services; The target computing engine framework forwards any blockchain task to the target computing unit when determining that the target computing unit is in an idle state; The target computing unit executes any of the blockchain tasks.

11. The method according to claim 10, wherein the second type list maintained by the scheduling engine records the computing type of each computing unit included in the off-chain computing node, and the scheduling engine determines the target computing unit matching the any blockchain task from the available services, comprising: The scheduling engine determines the target computing type corresponding to any blockchain task; The scheduling engine searches the second type list for a target computing unit corresponding to the target computing type.

12. According to the method of claim 7, the current startup of the off-chain computing node is a normal startup or a restart after an abnormal shutdown.

13. The method according to claim 6, wherein the target computing unit for processing the blockchain task is managed by a target computing engine framework, and the method further comprises: The target computing unit forwards the execution result of the blockchain task to the scheduling engine through the target computing engine framework; The scheduling engine submits the execution result to the blockchain node.

14. The method according to claim 13, wherein the scheduling engine submits the execution result to the blockchain node, comprising: Upon receiving the execution result forwarded by the target computing engine framework, the scheduling engine saves the execution result in a first result list maintained by itself; and, when it is determined that the execution result is successfully submitted to the blockchain node, the scheduling engine deletes the execution result saved in the first result list; and / or, Upon receiving the execution result sent by the target computing unit, the target computing engine framework saves the execution result in a second result list maintained by itself; Furthermore, when it is determined that the execution result is successfully forwarded to the scheduling engine, the target computing engine framework deletes the execution result stored in the second result list.

15. The method according to claim 6, wherein the blockchain node belongs to a blockchain subnet managed by a blockchain mainnet, the method further comprising: Submit the execution result of the blockchain task to the blockchain main network to store the execution result on the blockchain main network.

16. The method according to claim 6, wherein the blockchain transaction is used to instruct the blockchain node to call the workflow defined in the smart contract, and the execution result of the blockchain task is used to advance the workflow.

17. The method according to claim 1, The obtaining of the service change message from the service center includes: In the case where the scheduling engine has been registered with the service center, the scheduling engine obtains a service change message from the service center; The scheduling engine is registered with the service center in the following manner: when the scheduling engine is started, the scheduling engine initiates a service registration request to the service center to register the scheduling engine with the service registration center.

18. The method according to claim 1, wherein any change in a registered service includes at least one of the following: Adding any of the registered services, deleting any of the registered services, changing the service status of any of the registered services, and changing the call information of any of the registered services.

19. The method according to claim 1, wherein the available service information of any available service comprises at least one of the following: Service name, service type, service status, service call information, and current load information.

20. A service update device, applied to an off-chain computing node corresponding to a blockchain node, wherein the off-chain computing node includes a scheduling engine and a computing engine composed of a computing engine framework and computing units managed by the computing engine framework, and the scheduling engine is used to schedule blockchain tasks generated by the blockchain node to the computing engine for execution, the device comprising: A message acquisition unit, configured to acquire a service change message from a service center, wherein the service change message indicates a registered service after the change, wherein the registered service includes a computing engine framework and a computing unit registered with the service center; An information updating unit is configured to update locally maintained available service information according to the service change message, wherein the available service information is used to indicate available services in the registered services that are allowed to be called by the scheduling engine.

21. An electronic device comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 19 by running the executable instructions.

22. A computer-readable storage medium having computer instructions stored thereon, wherein when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 19 are implemented.

Images