Blockchain cross-chain task processing method and device, server and medium

Abstract

The application is suitable for the technical field of computers, and provides a blockchain cross-chain task processing method and device, a server and a medium, wherein the method comprises the following steps: receiving a cross-chain task request sent by a source chain; when the cross-chain task request indicates that a plurality of to-be-executed chains execute to-be-executed tasks, generating task execution information of subtasks required to be executed by each to-be-executed chain according to the cross-chain task request, wherein the task execution information is used for indicating that the to-be-executed chain executes the corresponding subtask; sending the corresponding task execution information to each to-be-executed chain respectively, and receiving a subtask execution result returned by each to-be-executed chain for the corresponding task execution information; and in the case that each received subtask execution result indicates execution success, determining that the to-be-executed task processing is successful. The application can realize parallel execution of cross-chain tasks in one-to-many scenarios, and is helpful to improve the processing efficiency of cross-chain tasks.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computers, and particularly relates to a cross-chain task processing method and device of a block chain, a server and a medium. BACKGROUND

[0002] A block chain is a distributed shared ledger and database, and has the characteristics of decentralization, non-tamperability, full traceability, collective maintenance, openness and transparency. With the development of the block chain technology, cross-chain interaction between block chains is needed. In practice, when cross-chain interaction between block chains is performed, it is usually necessary to ensure that cross-chain transactions between different chains are either both successfully executed or both restored to a state before execution (atomicity); it is also necessary to ensure that the states of the source chain and the destination chain are consistent before and after the execution of the cross-chain transaction (consistency); and it is also necessary to ensure that the source chain and the destination chain will not change the state due to the cross-chain transaction after the execution of the cross-chain transaction (durability).

[0003] In the related art, cross-chain interaction between block chains is usually one-to-one, that is, one block chain only interacts with another block chain, and the interaction efficiency is low. SUMMARY

[0004] The embodiments of the application provide a cross-chain task processing method and device of a block chain, a server and a medium, and aim to solve the problem of low interaction efficiency of one-to-one cross-chain interaction between block chains in the related art.

[0005] In a first aspect, the embodiments of the application provide a cross-chain task processing method of a block chain, which comprises the following steps.

[0006] receiving a cross-chain task request sent by a source chain;

[0007] When the cross-chain task request indicates that a plurality of to-be-executed chains execute to-be-executed tasks, generating, according to the cross-chain task request, task execution information of sub-tasks required to be executed by each to-be-executed chain, wherein the task execution information is used to indicate that the to-be-executed chain executes the corresponding sub-task;

[0008] sending the corresponding task execution information to each to-be-executed chain respectively, and receiving a sub-task execution result returned by each to-be-executed chain in response to the corresponding task execution information;

[0009] In the case where each received sub-task execution result indicates successful execution, it is determined that the to-be-executed task is processed successfully.

[0010] In some embodiments, after receiving the sub-task execution result returned by each to-be-executed chain in response to the corresponding task execution information, the method further comprises the following steps.

[0011] Adjust the task execution state of each to-be-executed chain corresponding subtask in the pre-created task state table to be adapted to the execution result of the corresponding to-be-executed chain corresponding subtask.

[0012] The task state table is used to record the task execution state of each subtask, and the task execution state includes an initial state, an execution failure state, an execution success state, and a rollback state.

[0013] In some embodiments, in the case that each received subtask execution result indicates execution success, it is determined that the to-be-executed task processing is successful, including:

[0014] In the case that the current timing value is less than the preset time threshold, and the task execution state of each subtask in the task state table is the execution success state, it is determined that the to-be-executed task processing is successful.

[0015] The timing starting point of the current timing value includes a time point at which the task execution state of each subtask in the task state table is set to the initial state, and a time point at which the task execution state of each subtask in the task state table is changed to the rollback state.

[0016] In some embodiments, the method further includes, in the case that the to-be-executed task processing fails, sending a rollback notification to each to-be-executed chain, and changing the task execution state of each to-be-executed chain corresponding subtask in the task state table to the rollback state, wherein the rollback notification is used to notify each to-be-executed chain to re-execute the corresponding subtask.

[0017] In some embodiments, after generating the task execution information of each to-be-executed chain required subtask to be executed, the method further includes:

[0018] According to the task execution information of each subtask, a task state table is created.

[0019] In some embodiments, the method further includes, in the case that the cross-chain task request indicates that the to-be-executed task is executed by one to-be-executed chain, sending the cross-chain task request to the to-be-executed chain.

[0020] Receiving a global task execution result returned by the to-be-executed chain for the cross-chain task request, and in the case that the global task execution result indicates execution success, determining that the to-be-executed task processing is successful.

[0021] In some embodiments, after receiving the cross-chain task request sent by the source chain, the method further includes determining the task type of the to-be-executed task according to the cross-chain task request, and in the case that the task type of the to-be-executed task is a cross-chain transfer task, determining that the source chain belongs to the to-be-executed chain.

[0022] The task type includes at least one of a cross-chain transfer task, a cross-chain forwarding task, and a cross-chain smart contract calling task.

[0023] In a second aspect, the embodiments of the present application provide a blockchain cross-chain task processing apparatus, which comprises:

[0024] a request receiving unit configured to receive a cross-chain task request sent by a source chain;

[0025] a task generating unit configured to, when the cross-chain task request indicates that a plurality of to-be-executed chains are required to execute a to-be-executed task, generate, according to the cross-chain task request, task execution information of a subtask required to be executed by each to-be-executed chain, wherein the task execution information is used to instruct the to-be-executed chain to execute the corresponding subtask;

[0026] a result receiving unit configured to send the corresponding task execution information to each to-be-executed chain respectively, and receive a subtask execution result returned by each to-be-executed chain for the corresponding task execution information;

[0027] a result determining unit configured to, when each received subtask execution result indicates that the execution is successful, determine that the to-be-executed task is processed successfully.

[0028] In some embodiments, the result receiving unit is specifically configured to: adjust a task execution state of the subtask corresponding to each to-be-executed chain in a pre-created task state table to be adapted to the subtask execution result corresponding to the corresponding to-be-executed chain;

[0029] wherein the task state table is used to record the task execution state of each subtask, and the task execution state comprises an initial state, an execution failure state, an execution success state, and a rollback state.

[0030] In some embodiments, the result determining unit is specifically configured to: when a current timing value is less than a preset time threshold, and the task execution state of each subtask in the task state table is the execution success state, determine that the to-be-executed task is processed successfully.

[0031] wherein the timing starting point of the current timing value comprises: a time point at which the task execution state of each subtask in the task state table is set to the initial state, and a time point at which the task execution state of each subtask in the task state table is changed to the rollback state.

[0032] In some embodiments, the apparatus further comprises a state rollback unit, wherein the state rollback unit is configured to, when the to-be-executed task is processed unsuccessfully, send a rollback notification to each to-be-executed chain, and change the task execution state of the subtask corresponding to each to-be-executed chain in the task state table to the rollback state, wherein the rollback notification is used to instruct each to-be-executed chain to re-execute the corresponding subtask.

[0033] In some embodiments, the task generating unit is further configured to create the task state table according to the task execution information of each subtask.

[0034] In some embodiments, the apparatus further includes a request sending unit and a result generating unit.

[0035] The request sending unit is configured to send the cross-chain task request to the to-be-executed chain when the cross-chain task request indicates that the to-be-executed task is executed by one to-be-executed chain.

[0036] The result generating unit is configured to receive a global task execution result returned by the to-be-executed chain for the cross-chain task request, and determine that the to-be-executed task processing is successful in a case where the global task execution result indicates that the execution is successful.

[0037] In some embodiments, the apparatus further includes a destination determining unit. The destination determining unit is configured to determine a task type of the to-be-executed task according to the cross-chain task request, and determine that the source chain belongs to the to-be-executed chain in a case where the task type of the to-be-executed task is a cross-chain transfer task.

[0038] The task type includes at least one of a cross-chain transfer task, a cross-chain forwarding task, and a cross-chain smart contract calling task.

[0039] In a third aspect, an embodiment of the present application provides a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of any of the above block chain cross-chain task processing methods when executing the computer program.

[0040] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores a computer program, and the above computer program implements the steps of any of the above block chain cross-chain task processing methods when executed by a processor.

[0041] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when executed on a server, causes the server to perform any of the above block chain cross-chain task processing methods.

[0042] Compared with the related art, the embodiment of the present application has the beneficial effects that one source chain can perform cross-chain interaction with multiple to-be-executed chains, and since the destination chain belongs to the to-be-executed chain, that is, one source chain can simultaneously perform cross-chain interaction with multiple destination chains, cross-chain task parallel execution in one-to-many scenarios can be realized, cross-chain task processing efficiency can be improved, and thus cross-chain interaction efficiency can be improved.

[0043] It can be understood that the beneficial effects of the above-mentioned second aspect to fifth aspect can be referred to the related description in the above-mentioned first aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or related description will be briefly introduced. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of these drawings.

[0045] Figure 1 is a flowchart of a blockchain cross-chain task processing method provided by an embodiment of the present application;

[0046] Figure 2 is a flowchart of a blockchain cross-chain task processing method provided by another embodiment of the present application;

[0047] Figure 3 is a structural diagram of a blockchain cross-chain task processing system provided by an embodiment of the present application;

[0048] Figure 4 is a structural diagram of a blockchain cross-chain task processing device provided by an embodiment of the present application;

[0049] Figure 5 is a structural diagram of a server provided by an embodiment of the present application. DETAILED DESCRIPTION

[0050] In the following description, specific details are set forth in order to provide a thorough understanding of embodiments of the present application. However, persons of ordinary skill in the art will readily recognize that embodiments of the present application can be practiced without these specific details. In other instances, well-known structures, devices, circuits, and methods have not been described in detail in order to avoid obscuring the present application.

[0051] It should be understood that, when used in the present application specification and the appended claims, the term "comprising" indicates the presence of described features, whole, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, whole, steps, operations, elements, components and / or sets thereof.

[0052] It should also be understood that the term "and / or" used in the present application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0053] As used in the specification and the appended claims, the term “if’ can be interpreted as meaning “when” or “upon” or “in response to determining” or “in response to detecting” depending on the context. Similarly, the phrase “if it is determined” or “if [a described condition or event] is detected” can be interpreted as meaning “upon determining” or “in response to determining” or “upon detecting [the described condition or event]” or “in response to detecting [the described condition or event]” depending on the context.

[0054] In addition, in the description of the present application and the appended claims, the terms “first”, “second”, “third”, etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0055] Reference in the specification to “one embodiment” or “some embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrases “in one embodiment”, “in some embodiments”, “in other embodiments”, “in additional embodiments” and so on, in various places in the specification are not necessarily all referring to the same embodiment, unless otherwise specifically stated. The terms “comprising”, “including”, “having” and their variants mean “including but not limited to”, unless otherwise specifically stated.

[0056] In order to illustrate the technical solutions of the present application, the following examples are used for illustration.

[0057] Continuing to refer to Figure 1 The embodiments of the present application provide a blockchain cross-chain task processing method, comprising:

[0058] Step 101, receiving a cross-chain task request sent by a source chain.

[0059] The cross-chain task request is generally information for requesting to process a cross-chain to-be-executed task. The to-be-executed task can be various tasks that need to be processed cross-chain. In practice, the task type of the to-be-executed task can include a cross-chain transfer task, a cross-chain forwarding task, and a cross-chain smart contract calling task. For example, the to-be-executed task can be a task of transferring 10 yuan from a blockchain A to a blockchain B and a blockchain C, a task of sending a file 1 of the blockchain A to the blockchain B and the blockchain C, and a task of calling a smart contract of the blockchain B and the blockchain C from the blockchain A.

[0060] In practice, the cross-chain task request described above usually follows an InterBlockchain Transfer Protocol (IBTP). The IBTP protocol supports cross-chain transactions and trusted verification between heterogeneous blockchains. The IBTP protocol data usually includes a From field, a To field, a Version field, an Index field, a Payload field, a Timestamp field, a Proof field, an Extra field, and the like.

[0061] The source chain is usually the blockchain that initiates the cross-chain task request. The destination chain is usually the blockchain that is initiated by the cross-chain task request.

[0062] In this embodiment, the execution subject of the blockchain cross-chain task processing method is usually a relay chain between the source chain and the destination chain, and can be a server corresponding to the relay chain.

[0063] In practice, the source chain can send a cross-chain task request to the relay chain when receiving a task processing request sent by a user terminal for requesting processing of a to-be-executed task. In actual application, the user terminal in communication connection with the source chain can send a task processing request to the source chain, and the task processing request is used to request processing of a to-be-executed task. As an example, the task processing request can be “please help forward file 1 to blockchain B and blockchain C respectively”. When receiving the task processing request, the source chain can generate a cross-chain task request following the IBTP protocol using part or all of the information in the task processing request, that is, the cross-chain task request is IBTP protocol data. Then, the cross-chain task request is sent to the relay chain through the network. In this way, the relay chain can receive the cross-chain task request.

[0064] In actual application, when the source chain A receives a task processing request and the task processing request is “please help forward file 1 to blockchain B, blockchain C, and blockchain D respectively”, the source chain can generate a cross-chain task request following the IBTP protocol. In the cross-chain task request, the content of the From field is A, the content of the To field can be B, and the content of the Group field can be C and D. The Group field is a custom field for writing destination chain identifiers.

[0065] In addition, when the task processing request is "please help forward file 1 to blockchain B", the content of the From field in the cross-chain task request generated by the source chain in compliance with the IBTP protocol is A, the content of the To field is B, and the content of the Group field is usually empty.

[0066] At step 102, when the cross-chain task request indicates that the to-be-executed task is to be executed by multiple to-be-executed chains, according to the cross-chain task request, task execution information of a sub-task required to be executed by each to-be-executed chain is generated respectively.

[0067] The task execution information is used to instruct the to-be-executed chain to execute the corresponding sub-task. The to-be-executed chain is usually a blockchain participating in the execution of at least part of the to-be-executed task. In practice, the destination chain belongs to the to-be-executed chain. The destination chain can have one or more.

[0068] In actual application, when the relay chain receives the cross-chain task request, it can parse the cross-chain task request to obtain the content of each field, and determine the destination chain by analyzing the content of each field. For example, if the content of the Group field in the cross-chain task request is empty and the content of the To field is B, it indicates that there is one destination chain, and the destination chain is blockchain B. If the content of the Group field in the cross-chain task request is C and D, and the content of the To field is B, it indicates that there are three destination chains, and the destination chains are blockchain B, blockchain C and blockchain D.

[0069] Generally, the destination chain is the to-be-executed chain. When the cross-chain task request indicates that the to-be-executed task is to be executed by multiple to-be-executed chains, the relay chain can generate a sub-task and corresponding task execution information for each to-be-executed chain in combination with the information carried in the cross-chain task request.

[0070] It should be noted that in the application scenario where the cross-chain task request carries information indicating the task type of the to-be-executed task, the relay chain can also determine the to-be-executed chain in combination with the task type of the to-be-executed task. At this time, in some task types, the to-be-executed chain can include the destination chain and the source chain, and in other task types, the to-be-executed chain only includes the destination chain.

[0071] As an example, if the cross-chain task request indicates that the to-be-executed task is to send file 1 in blockchain A to blockchain B and blockchain C at the same time. At this time, the task type is a cross-chain forwarding task, and the to-be-executed chain only includes the destination chain, that is, the to-be-executed chain can be blockchain B and blockchain C. The relay chain can generate task execution information 1 for blockchain B, which indicates that the sub-task 1 is to receive and store file 1 in blockchain A by blockchain B. Task execution information 2 can be generated for blockchain C, which indicates that the sub-task 2 is to receive and store file 1 in blockchain A by blockchain C.

[0072] As another example, if the cross-chain task request indicates that the task to be executed is: transferring 10 yuan from the blockchain A to the blockchain B and the blockchain C. At this time, the task type is a cross-chain transfer task, and the task to be executed includes the destination chain and the source chain, that is, the to-be-executed chain can be the blockchain A, the blockchain B and the blockchain C. The relay chain can generate task execution information 1 for the blockchain B, and the indicated subtask 1 is: the blockchain B increases the account balance by 10 yuan. The task execution information 2 is generated for the blockchain C, and the indicated subtask 2 is: the blockchain C increases the account balance by 10 yuan. The task execution information 3 is generated for the blockchain A, and the indicated subtask 3 is: the blockchain A reduces the account balance by 20 yuan.

[0073] In step 103, the corresponding task execution information is sent to each to-be-executed chain respectively, and the subtask execution result returned by each to-be-executed chain for the corresponding task execution information is received.

[0074] Here, for each to-be-executed chain, the relay chain can send the task execution information for the to-be-executed chain to the to-be-executed chain. In this way, the to-be-executed chain can receive the task execution information and can execute the corresponding subtask based on the task execution information. After the to-be-executed chain executes the corresponding subtask, the obtained subtask execution result can be sent to the relay chain.

[0075] For example, if the task execution information received by the to-be-executed chain B indicates that the blockchain B increases the account balance by 10 yuan. When the blockchain B executes the subtask corresponding to the task execution information, it can obtain a subtask execution result indicating the success or failure of the execution. Then, the blockchain B can return the subtask execution result to the relay chain.

[0076] It should be noted that the relay chain can also actively send a query request for querying the subtask execution result to the to-be-executed chain, so as to obtain the subtask execution result of the to-be-executed chain. The specific manner in which the relay chain obtains the subtask execution result of the to-be-executed chain is not limited in this embodiment.

[0077] In step 104, in the case where each of the received subtask execution results indicates the success of the execution, it is determined that the to-be-executed task is processed successfully.

[0078] Here, the relay chain can receive the subtask execution result returned by each to-be-executed chain. In the case where all the received subtask execution results indicate the success of the execution, the relay chain can determine that the to-be-executed task is processed successfully.

[0079] In practice, in the case where there is a subtask execution result indicating the failure of the execution, the relay chain can determine that the to-be-executed task is processed unsuccessfully. In this way, the consistency of cross-chain interaction can be ensured.

[0080] Optionally, the determining that the to-be-executed task processing is successful in the case that each received sub-task execution result indicates a successful execution can comprise: determining that the to-be-executed task processing is successful in the case that the current timing value is less than the preset time threshold and each received sub-task execution result indicates a successful execution.

[0081] The time threshold is usually a preset value indicating a time length. In practice, the preset time threshold is usually small, for example, 8 seconds, 10 seconds, etc. The timing starting point of the current timing value can comprise a time point at which the task execution information is sent to each to-be-executed chain. The current timing value usually refers to a time difference from the timing starting point to the current time. For example, if the timing starting point is 8:10:12 and the current time is 8:10:20, the current timing value is 8 seconds.

[0082] Here, only in the case that the current timing value is less than the preset time threshold and all received sub-task execution results indicate a successful execution, the relay chain considers that the to-be-executed task processing is successful. Otherwise, the relay chain considers that the to-be-executed task processing is unsuccessful. For example, if there are four to-be-executed chains, when the preset time threshold is reached, if the relay chain receives three sub-task execution results, and the three sub-task execution results all indicate a successful execution, the relay chain can determine that the to-be-executed task processing is unsuccessful.

[0083] It should be noted that since the preset time threshold is usually small, at most waiting for a time length corresponding to the preset time threshold for one task execution can reduce the cross-chain interaction time length of each time, thereby further improving the cross-chain interaction efficiency.

[0084] The method provided in this embodiment can enable one source chain to perform cross-chain interaction with multiple to-be-executed chains. Since the destination chain belongs to the to-be-executed chain, that is, one source chain can simultaneously perform cross-chain interaction with multiple destination chains, cross-chain task parallel execution in a one-to-many scenario can be realized, and the cross-chain task processing efficiency can be improved, thereby helping to improve the cross-chain interaction efficiency.

[0085] Optionally, the blockchain cross-chain task processing method can further comprise: sending information indicating that the to-be-executed task processing is successful to the source chain when the to-be-executed task processing is successful. In this way, the source chain can accurately know the processing of the entire to-be-executed task.

[0086] In the optional implementation of each embodiment of the present application, after receiving the sub-task execution result returned by each to-be-executed chain for the corresponding task execution information, the method can further comprise: adjusting the task execution state of each to-be-executed chain corresponding sub-task in the pre-created task state table to adapt to the corresponding to-be-executed chain corresponding sub-task execution result.

[0087] The task state table is used to record the task execution state of each subtask, and the task execution state can include an initial state, an execution failure state, an execution success state, and a rollback state. The task state table records the task execution state of each subtask. In practice, the task state table can include multiple records, and each record is the task identifier of a corresponding subtask and the task execution state of the subtask.

[0088] In practice, the task state table usually corresponds to the task identifier of the to-be-executed task. For example, the task execution state of the to-be-executed task can be recorded in the task state table. The task state table corresponding to the task identifier of the to-be-executed task helps to uniformly manage information related to the same to-be-executed task and further improve cross-chain interaction efficiency.

[0089] Here, for each to-be-executed chain, after receiving the subtask execution result returned by the to-be-executed chain, the relay chain can adjust the task execution state of the subtask corresponding to the to-be-executed chain in the task state table to be adapted to the subtask execution result of the to-be-executed chain. For example, for the to-be-executed chain B, after receiving the subtask execution result returned by the to-be-executed chain B, if the subtask execution result indicates an execution failure, the relay chain can update the task execution state of the subtask corresponding to the to-be-executed chain B in the task state table to the execution failure state.

[0090] Here, the task state table can be used to accurately and orderly store the task execution state of each subtask, and can be used to flexibly and efficiently update the task execution state of the subtask, which helps to further improve cross-chain interaction efficiency.

[0091] In some optional implementation manners, after generating the task execution information of the subtask to be executed by each to-be-executed chain, the relay chain can create a task state table according to the task execution information of each subtask.

[0092] Here, after obtaining the task execution information of the subtask to be executed by each to-be-executed chain, the relay chain can generate a task state table using all the task execution information. Specifically, for each subtask, the attribute information of the task execution information corresponding to the subtask can be used to generate the task identifier of the subtask, and the initial state can be determined as the task execution state of the subtask. The attribute information of the task execution information can include the task execution information itself and / or the information identifier of the task execution information.

[0093] In some optional implementation, in the step 104, in the case that the received execution result of each subtask indicates success, determining that the to-be-executed task is processed successfully can comprise: determining that the to-be-executed task is processed successfully when the task execution state of each subtask in the task state table is the execution success state.

[0094] Here, since the task execution state of each subtask is recorded in the task state table, the relay chain can determine whether the to-be-executed task is processed successfully by analyzing the task execution state of each subtask in the task state table.

[0095] Specifically, when the task execution state of each subtask in the task state table is the execution success state, the relay chain can consider that the to-be-executed task is processed successfully. When the task execution state of a subtask in the task state table is the execution failure state, the relay chain can consider that the to-be-executed task is processed unsuccessfully.

[0096] In some optional implementation, in the step 104, in the case that the received execution result of each subtask indicates success, determining that the to-be-executed task is processed successfully can also comprise: determining that the to-be-executed task is processed successfully when the current timing value is less than the preset time threshold and the task execution state of each subtask in the task state table is the execution success state.

[0097] Here, the timing starting point of the current timing value can comprise: the time point when the task execution state of each subtask in the task state table is set to the initial state, and the time point when the task execution state of each subtask in the task state table is changed to the rollback state. The current timing value is usually the time difference from the timing starting point to the current time.

[0098] Here, the time threshold is usually a numerical value indicating the preset time. In practice, the preset time threshold is usually small, for example, it can be 8 seconds, 10 seconds, etc.

[0099] Here, only when the current timing value is less than the preset time threshold and the task execution state of each subtask in the task state table is the execution success state, the relay chain considers that the to-be-executed task is processed successfully. Otherwise, the relay chain considers that the to-be-executed task is processed unsuccessfully. For example, if there are 4 to-be-executed chains, when the preset time threshold is reached, if there are 3 subtasks in the task state table whose task execution state is the execution success state, and 1 subtask whose task execution state is not the execution success state, such as the initial state or the execution failure state, the relay chain can determine that the to-be-executed task is processed unsuccessfully.

[0100] In practice, since the preset time threshold is usually small, at most waiting for a time corresponding to the preset time threshold for one task execution can reduce the time length of each cross-chain interaction, thereby further improving the cross-chain interaction efficiency.

[0101] In some optional implementations, the above blockchain cross-chain task processing method can include: in the case of failure to process the to-be-executed task, sending a rollback notification to each to-be-executed chain. The rollback notification is used to notify each to-be-executed chain to re-execute the corresponding subtask.

[0102] Here, in the case of failure to process the to-be-executed task, the relay chain can send a rollback notification to each to-be-executed chain. In this way, each to-be-executed chain can re-execute the corresponding subtask, and return the subtask execution result obtained after re-executing the subtask to the relay chain. In this way, the relay chain can determine the processing result of the to-be-executed task based on all the subtask execution results returned by the to-be-executed chains in the new round. It can be ensured that the source chain and the to-be-executed chain involved in the cross-chain interaction are either both successfully executed or both restored to the unexecuted state or re-executed, which helps to ensure the atomicity of the cross-chain interaction.

[0103] In some optional implementations, the above blockchain cross-chain task processing method can also include: in the case of failure to process the to-be-executed task, sending a rollback notification to each to-be-executed chain, and changing the task execution state of each to-be-executed chain corresponding to the subtask in the task state table to a rollback state. The rollback notification is used to notify each to-be-executed chain to re-execute the corresponding subtask.

[0104] Here, in the case of failure to process the to-be-executed task, the relay chain can send a rollback notification to each to-be-executed chain, which can ensure that the source chain and the to-be-executed chain involved in the cross-chain interaction are either both successfully executed or both restored to the unexecuted state or re-executed, which helps to ensure the atomicity of the cross-chain interaction.

[0105] In addition, in the case of failure to process the to-be-executed task, the relay chain changes the task execution state of each to-be-executed chain corresponding to the subtask in the task state table to a rollback state in a timely manner, which can realize quick and accurate updating of the task execution state of each subtask in the task state table, and helps to further improve the cross-chain interaction efficiency.

[0106] In some optional implementations of the present embodiment, the above blockchain cross-chain task processing method can further include the following step one and step two.

[0107] Step one: when the cross-chain task request indicates that the to-be-executed task is executed by one to-be-executed chain, sending the cross-chain task request to the to-be-executed chain.

[0108] Here, when the cross-chain task request indicates that the above to-be-executed task is executed by one to-be-executed chain, the relay chain can directly send the cross-chain task request to the to-be-executed chain. For example, if the cross-chain task request indicates that the to-be-executed task is to send file 1 in blockchain A to blockchain B. At this time, the to-be-executed chain is blockchain B, and there is only one to-be-executed chain. The relay chain can send the cross-chain task request to the to-be-executed chain, so as to realize that the to-be-executed task is received and stored by blockchain B, that is, the to-be-executed task is executed by blockchain B.

[0109] Step two, receiving the global task execution result returned by the to-be-executed chain for the cross-chain task request, and determining that the to-be-executed task is processed successfully in the case that the global task execution result indicates that the execution is successful.

[0110] Here, the above global task execution result is the execution result of the to-be-executed task by the to-be-executed chain.

[0111] Here, the to-be-executed chain can execute the to-be-executed task, and send the obtained global task execution result to the relay chain. In this way, the relay chain can receive the global task execution result, and determine that the to-be-executed task is processed successfully when the global task execution result indicates that the execution is successful. If the global task execution result indicates that the execution fails, it can be determined that the to-be-executed task is processed unsuccessfully.

[0112] In the optional implementation of each embodiment of the present application, after receiving the cross-chain task request sent by the source chain, the above blockchain cross-chain task processing method can further include: determining the task type of the to-be-executed task according to the cross-chain task request, and determining that the source chain belongs to the to-be-executed chain when the task type of the to-be-executed task is a cross-chain transfer task.

[0113] Here, the task type includes at least one of a cross-chain transfer task, a cross-chain forwarding task, and a cross-chain smart contract calling task.

[0114] Here, the relay chain can determine the task type of the to-be-executed task in combination with the information carried in the cross-chain task request. When the task type of the to-be-executed task is a cross-chain transfer task, the relay chain can consider that the source chain belongs to the to-be-executed chain, and at this time, the to-be-executed chain includes the destination chain and the source chain.

[0115] Continuing to refer to Figure 2 A flowchart of a blockchain cross-chain task processing method provided by an embodiment of the present application is shown in FIG. 2. As shown in FIG. 2, the blockchain cross-chain task processing method can include the following steps 201 to 206. Figure 2

[0116] Step 201, the source chain sends a cross-chain task request to the relay chain.

[0117] ​In step 202, the relay chain determines the sub-tasks of each to-be-executed chain, and creates a state record table.

[0118] Here, when the cross-chain task request indicates that the to-be-executed task is to be executed by multiple to-be-executed chains, the relay chain can generate, according to the cross-chain task request, task execution information of the sub-tasks required to be executed by each to-be-executed chain. Then, the relay chain can create a task state table according to the task execution information of each sub-task.

[0119] As shown in Figure 2 The task type of the to-be-executed task is a cross-chain transfer task, and the source chain belongs to the to-be-executed chain. At this time, the to-be-executed chain includes the destination chain and the source chain, that is, the to-be-executed chain includes the destination chain 1, the destination chain 2, and the source chain. Figure 2 In the state record table obtained, three records can be included, and each record includes a corresponding sub-task identifier and a task execution state of the sub-task. Specifically, “Transaction 1” is the sub-task identifier of the sub-task 1 corresponding to the destination chain 1, “Transaction 2” is the sub-task identifier of the sub-task 2 corresponding to the destination chain 2, and “Transaction 3” is the sub-task identifier of the sub-task 3 corresponding to the source chain. The initial task execution state of each sub-task in the initial state record table is “BEGIN”, that is, the initial state. Figure 2 In the state record table obtained, three records can be included, and each record includes a corresponding sub-task identifier and a task execution state of the sub-task. Specifically, “Transaction 1” is the sub-task identifier of the sub-task 1 corresponding to the destination chain 1, “Transaction 2” is the sub-task identifier of the sub-task 2 corresponding to the destination chain 2, and “Transaction 3” is the sub-task identifier of the sub-task 3 corresponding to the source chain. The initial task execution state of each sub-task in the initial state record table is “BEGIN”, that is, the initial state.

[0120] Figure 2 In the state record table obtained, three records can be included, and each record includes a corresponding sub-task identifier and a task execution state of the sub-task. Specifically, “Transaction 1” is the sub-task identifier of the sub-task 1 corresponding to the destination chain 1, “Transaction 2” is the sub-task identifier of the sub-task 2 corresponding to the destination chain 2, and “Transaction 3” is the sub-task identifier of the sub-task 3 corresponding to the source chain. The initial task execution state of each sub-task in the initial state record table is “BEGIN”, that is, the initial state. Figure 2 When the timeout block height is reached, if there is a record in the task state table with a task execution state other than “SUCCESS”, the relay chain can consider that the to-be-executed task processing fails.

[0121] In actual application, the calculation starting point of the timeout block height can include at least one of the following: the time point when the task execution state of each sub-task in the task state table is set to the initial state, and the time point when the task execution state of each sub-task in the task state table is changed to the rollback state.

[0122] It should be noted that when the timeout block height is a pre-set time length, the timeout block height and the pre-set time threshold have basically the same concept and usage.

[0123] In step 203, the relay chain sends the corresponding task execution information to each to-be-executed chain.

[0124] The task execution information is used to instruct the to-be-executed chain to execute the corresponding sub-task.

[0125] Here, when the task type to be executed is a cross-chain transfer task, the source chain is the chain to be executed. At this time, the relay chain sends task execution information to both the source chain and the destination chain.

[0126] Step 204: The corresponding subtasks of the execution chain are executed.

[0127] Figure 2 In the process, destination chain 1 executes subtask 1, destination chain 2 executes subtask 2, and source chain executes subtask 3.

[0128] Step 205: The execution chain returns the subtask execution result to the relay chain.

[0129] Here, each chain to be executed can return the result of the subtask execution to the relay chain after executing the subtask.

[0130] Step 206: The relay chain determines the processing result of the task to be executed.

[0131] Here, because the execution results of the subtasks returned by each execution chain are in a specific order, the relay chain can adjust the execution status of the corresponding subtask in the status record table to match the execution result of that execution chain when it receives the subtask execution result. For example, if the execution result of the subtask corresponding to that execution chain indicates successful execution, then the execution status of the corresponding subtask in the status record table will be adjusted to the successful execution status.

[0132] The relay chain can determine the processing result of the task to be executed when it obtains the execution results of all subtasks in the pending execution chain, or when it reaches the timeout block height. For example, if the execution results of all subtasks in the pending execution chain are obtained before reaching the timeout block height, and the task execution status of the subtask corresponding to each pending execution chain in the status record table is "SUCCESS", then it can be determined that the task to be executed has been successfully processed.

[0133] In practice, when a task is successfully processed, the relay chain can send a message to the source chain indicating successful processing. If a task fails, the relay chain can send a rollback notification to each chain awaiting execution and change the task execution status of the subtask corresponding to each chain in the task status table to "ROLLBACK". The rollback notification instructs each chain to re-execute its corresponding subtask.

[0134] Continue to refer to Figure 3 This is a schematic diagram of the structure of a blockchain cross-chain task processing system provided in an embodiment of this application. Figure 3As shown, the blockchain cross-chain task processing system can include a source chain 301, a relay chain 302, and at least one destination chain 303.

[0135] The source chain 301 is configured to send a cross-chain task request.

[0136] The relay chain 302 is configured to receive the cross-chain task request, and when the cross-chain task request indicates that the to-be-executed task is to be executed by a plurality of to-be-executed chains, generate, according to the cross-chain task request, task execution information of a subtask required to be executed by each to-be-executed chain, wherein the task execution information is used to instruct the to-be-executed chain to execute the corresponding subtask, and send the corresponding task execution information to each to-be-executed chain.

[0137] Generally, the destination chain is the to-be-executed chain. When the cross-chain task request indicates that the to-be-executed task is to be executed by a plurality of to-be-executed chains, the relay chain can generate a subtask and corresponding task execution information for each to-be-executed chain in combination with information carried in the cross-chain task request.

[0138] It should be noted that in the application scenario where the cross-chain task request carries information indicating the task type of the to-be-executed task, the relay chain can also determine the to-be-executed chain in combination with the task type of the to-be-executed task. At this time, in some task types, the to-be-executed chain can include both the destination chain and the source chain, and in other task types, the to-be-executed chain only includes the destination chain.

[0139] The destination chain 303 or the source chain 301 is configured to receive the task execution information, execute the subtask indicated by the task execution information, and return the subtask execution result to the relay chain.

[0140] The relay chain 302 is further configured to receive the subtask execution result returned by each to-be-executed chain for the corresponding task execution information, and determine that the to-be-executed task is processed successfully when each received subtask execution result indicates that the execution is successful.

[0141] The blockchain cross-chain task processing system provided in this embodiment can perform cross-chain interaction with a plurality of to-be-executed chains from one source chain. Since the destination chain belongs to the to-be-executed chain, that is, one source chain can simultaneously perform cross-chain interaction with a plurality of destination chains, cross-chain task parallel execution in a one-to-many scenario can be realized, and cross-chain task processing efficiency can be improved, thereby helping to improve cross-chain interaction efficiency.

[0142] It should be noted that the information interaction, execution process, and the like between the above source chain, relay chain, and destination chain are based on the same concept as the method embodiments of the present application, and the specific functions and technical effects brought about thereby can be referred to the method embodiments part, which will not be described here.

[0143] Corresponding to the blockchain cross-chain task processing method of the above embodiment one,Figure 4 A structural block diagram of the blockchain cross-chain task processing apparatus 400 provided by the embodiments of the present application is shown, and only parts related to the embodiments of the present application are shown for ease of illustration.

[0144] With reference to Figure 4 The apparatus comprises:

[0145] A request receiving unit 401 configured to receive a cross-chain task request sent by a source chain;

[0146] A task generating unit 402 configured to, when the cross-chain task request indicates that a plurality of to-be-executed chains are required to execute a to-be-executed task, generate, according to the cross-chain task request, task execution information of a subtask required to be executed by each to-be-executed chain, wherein the task execution information is used to instruct the to-be-executed chain to execute the corresponding subtask.

[0147] A result receiving unit 403 configured to send the corresponding task execution information to each to-be-executed chain respectively, and receive a subtask execution result returned by each to-be-executed chain in response to the corresponding task execution information;

[0148] A result determining unit 404 configured to, when each received subtask execution result indicates a successful execution, determine that the to-be-executed task is processed successfully.

[0149] In some embodiments, the result receiving unit 403 is specifically configured to adjust a task execution state of each subtask corresponding to each to-be-executed chain in a pre-created task state table to be adapted to a subtask execution result corresponding to the corresponding to-be-executed chain. The task state table is used to record the task execution state of each subtask, and the task execution state comprises an initial state, an execution failure state, an execution success state, and a rollback state.

[0150] In some embodiments, the result determining unit 404 is specifically configured to, when a current timing value is less than a preset time threshold and the task execution state of each subtask in the task state table is the execution success state, determine that the to-be-executed task is processed successfully. The timing starting point of the current timing value comprises a time point at which the task execution state of each subtask in the task state table is set to the initial state, and a time point at which the task execution state of each subtask in the task state table is changed to the rollback state.

[0151] In some embodiments, the apparatus further comprises a state rollback unit. The state rollback unit is configured to, when the to-be-executed task is processed unsuccessfully, send a rollback notification to each to-be-executed chain, and change the task execution state of each subtask corresponding to each to-be-executed chain in the task state table to the rollback state. The rollback notification is used to instruct each to-be-executed chain to re-execute the corresponding subtask.

[0152] In some embodiments, the task generation unit 402 is further configured to create a task status table based on the task execution information of each subtask.

[0153] In some embodiments, the apparatus further includes a request sending unit and a result generating unit. The request sending unit is configured to send a cross-chain task request to a pending chain when the cross-chain task request indicates that the task to be executed should be performed by a pending chain. The result generating unit is configured to receive a global task execution result returned by the pending chain in response to the cross-chain task request, and, if the global task execution result indicates successful execution, determine that the task to be executed has been successfully processed.

[0154] In some embodiments, the apparatus further includes a destination determination unit. This destination determination unit is configured to determine the task type of the task to be executed based on the cross-chain task request, and, when the task type of the task to be executed is a cross-chain transfer task, determine that the source chain belongs to the chain to be executed. The task type includes at least one of a cross-chain transfer task, a cross-chain forwarding task, and a cross-chain smart contract call task.

[0155] The device provided in this embodiment allows one source chain to interact with multiple execution chains across chains. Since the destination chain is an execution chain, one source chain can interact with multiple destination chains across chains simultaneously. This enables parallel execution of cross-chain tasks in one-to-many scenarios, improves the efficiency of cross-chain task processing, and thus helps improve the efficiency of cross-chain interaction.

[0156] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiment 1 of this application. For details on their specific functions and technical effects, please refer to the method embodiment section, which will not be repeated here.

[0157] Figure 5 This is a schematic diagram of the structure of a server 500 provided in one embodiment of this application. Figure 5 As shown, the server 500 in this embodiment includes: at least one processor 501 ( Figure 5 The diagram shows only one processor, memory 502, and a computer program 503, such as a data processing program, stored in memory 502 and executable on at least one processor 501. When processor 501 executes computer program 503, it implements the steps in any of the above method embodiments. When processor 501 executes computer program 503, it implements the steps in the embodiments of the above blockchain cross-chain task processing methods. When processor 501 executes computer program 503, it implements the functions of each module / unit in the above device embodiments, for example... Figure 4 The functions of the request receiving unit 401 to the result determining unit 404 are shown.

[0158] For example, the computer program 503 can be divided into one or more modules / units, one or more modules / units are stored in the memory 502 and executed by the processor 501 to complete the present application. One or more modules / units can be a series of computer program instruction segments capable of completing a specific function, which are used to describe the execution process of the computer program 503 in the server 500. For example, the computer program 503 can be divided into a request receiving unit, a task generating unit, a result receiving unit, a result determining unit, and the specific functions of each unit are described in the above embodiments, which will not be repeated here.

[0159] The server 500 can be a server, a desktop computer, a tablet computer, a cloud server, and a mobile terminal, etc. The server 500 can include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art can understand that the server 500 can include more or less components, or combine some components, or different components, for example, the server can also include an input / output device, a network access device, a bus, etc. Figure 5 The server 500 is only an example and does not constitute a limitation on the server 500, and can include more or less components than the illustration, or combine some components, or different components, for example, the server can also include an input / output device, a network access device, a bus, etc.

[0160] The processor 501 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0161] The memory 502 can be an internal storage unit of the server 500, such as a hard disk or a memory of the server 500. The memory 502 can also be an external storage device of the server 500, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the memory 502 can include both the internal storage unit and the external storage device of the server 500. The memory 502 is used to store computer programs and other programs and data required by the server. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0162] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be realized in the form of hardware or software function unit. In addition, the specific name of each functional unit and module is only for the convenience of mutual distinction, and does not limit the protection scope of the present application. The specific working process of the unit and module in the above system can refer to the corresponding process in the foregoing method embodiment, which will not be described here.

[0163] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described or recorded in detail in a certain embodiment can be referred to the related description of other embodiments.

[0164] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0165] In the embodiments provided in the present application, it should be understood that the disclosed devices / servers and methods can be implemented in other ways. For example, the device / server embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division, and there can be another division in actual implementation. 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 shown or discussed mutual elements can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0166] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0167] In addition, each of the function units in each of the embodiments of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software function unit.

[0168] If the integrated module is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of each method embodiment described above can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0169] The above embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for processing cross-chain tasks of a blockchain, characterized in that, The method is executed by a relay chain, and the method comprises: receiving a cross-chain task request sent by a source chain; when the cross-chain task request indicates that a plurality of to-be-executed chains are required to execute a to-be-executed task, generating, according to the cross-chain task request, task execution information of a subtask required to be executed by each to-be-executed chain, wherein the task execution information is used to instruct the to-be-executed chain to execute the corresponding subtask; sending the corresponding task execution information to each to-be-executed chain respectively, and receiving a subtask execution result returned by each to-be-executed chain for the corresponding task execution information; when each received subtask execution result indicates that the execution is successful, determining that the to-be-executed task is processed successfully; after receiving the subtask execution result returned by each to-be-executed chain for the corresponding task execution information, the method further comprises: adjusting a task execution state of the subtask corresponding to each to-be-executed chain in a pre-created task state table to be adapted to the subtask execution result corresponding to the corresponding to-be-executed chain; wherein the task state table is used to record the task execution state of each subtask, and the task execution state comprises an initial state, an execution failure state, an execution success state, and a rollback state. 2.The method of claim 1, wherein, The method further comprises: when a current timing value is less than a preset time threshold, and the task execution state of each subtask in the task state table is the execution success state, determining that the to-be-executed task is processed successfully; wherein the timing starting point of the current timing value comprises a time point at which the task execution state of each subtask in the task state table is set to the initial state, and a time point at which the task execution state of each subtask in the task state table is changed to the rollback state. 3.The method of claim 1, wherein, The method further comprises: when the to-be-executed task is processed unsuccessfully, sending a rollback notification to each to-be-executed chain, and changing the task execution state of the subtask corresponding to each to-be-executed chain in the task state table to the rollback state, wherein the rollback notification is used to instruct each to-be-executed chain to re-execute the corresponding subtask. 4.The method of claim 1, wherein, After generating the task execution information of the subtask required to be executed by each to-be-executed chain, the method further comprises: creating the task state table according to the task execution information of each subtask. 5.The method of claim 1, wherein, The method further comprises: when the cross-chain task request indicates that one to-be-executed chain is required to execute the to-be-executed task, sending the cross-chain task request to the to-be-executed chain; receiving a global task execution result returned by the to-be-executed chain for the cross-chain task request, and determining that the to-be-executed task is processed successfully when the global task execution result indicates that the execution is successful. 6.The method of claim 1-5, wherein, After receiving the cross-chain task request sent by the source chain, the method further comprises: determining a task type of the to-be-executed task according to the cross-chain task request, and determining that the source chain belongs to a to-be-executed chain when the task type of the to-be-executed task is a cross-chain transfer task; wherein the task type comprises at least one of a cross-chain transfer task, a cross-chain forwarding task, and a cross-chain smart contract calling task. 7.A blockchain cross-chain task processing apparatus characterized by comprising: The device is configured in a relay chain, and the device comprises: a request receiving unit configured to receive a cross-chain task request sent by a source chain; a task generating unit configured to, when the cross-chain task request indicates that a plurality of to-be-executed chains are required to execute a to-be-executed task, generate, according to the cross-chain task request, task execution information of a subtask required to be executed by each to-be-executed chain, wherein the task execution information is used to instruct the to-be-executed chain to execute the corresponding subtask; a result receiving unit configured to send the corresponding task execution information to each to-be-executed chain respectively, and receive a subtask execution result returned by each to-be-executed chain for the corresponding task execution information; a result determining unit configured to, when each received subtask execution result indicates that the execution is successful, determine that the to-be-executed task is processed successfully. The result receiving unit is specifically configured to adjust a task execution state of each to-be-executed chain corresponding subtask in a pre-created task state table to be adapted to a corresponding to-be-executed chain corresponding subtask execution result; wherein the task state table is used to record a task execution state of each subtask, and the task execution state comprises an initial state, an execution failure state, an execution success state, and a rollback state.

8. A server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method of any one of claims 1 to 6.

9. A computer readable storage medium, the storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 6.

Images