Data processing method and apparatus

Abstract

Embodiments of the present specification provide a data processing method and device. The method is applied to a first computing engine, a first blockchain node is deployed in a first node device where the first computing engine is located, and an off-chain computing contract is deployed in a blockchain network to which the first blockchain node belongs; the method comprises: receiving a data acquisition request initiated by a request party for target data, the data acquisition request containing a timestamp, a data identifier of the target data, a public key of the request party, and a signature generated by the request party based on a private key of the request party on the timestamp, the data identifier and the public key; in a case where the timestamp and the public key indicate that the request party is a second computing engine, returning the target data to the second computing engine for performing an off-chain collaboration task generated by the off-chain computing contract, the second computing engine and a second blockchain node belonging to a second node device.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology in one or more embodiments, and more particularly to a data processing method and apparatus. Background Technology

[0002] Blockchain technology is built on top of transmission networks (such as peer-to-peer networks). Nodes in a blockchain network use a chained data structure to verify and store data, and employ distributed node consensus algorithms to generate and update data. Smart contracts deployed in a blockchain can generate blockchain tasks that need to be executed off-chain. During the execution of this task by multiple blockchain nodes, the relevant parties corresponding to each blockchain node may need to interact with data. For example, the administrator of any blockchain node may need to provide data it maintains to the requesting parties of other blockchain nodes so that the latter can use this data to execute the aforementioned blockchain task.

[0003] In related technologies, requesters typically add their own signature to their data retrieval requests so that administrators can provide the required data only if the signature is verified. While this approach provides some access control over the retrieved data, it still struggles to prevent replay attacks: the requester's data retrieval request might be intercepted by a third party and resent to the administrator. Since the replay request still contains the requester's signature, it can still pass the administrator's verification and be processed normally, resulting in the data maintained by the administrator being exported to a third party, posing a significant security risk. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide a data processing method and apparatus.

[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0006] According to a first aspect of one or more embodiments of this specification, a data processing method is proposed, applied to a first computing engine, wherein a first blockchain node is deployed in a first node device where the first computing engine is located, and an off-chain computing contract is deployed on the blockchain network to which the first blockchain node belongs; the method includes:

[0007] The system receives a data acquisition request initiated by a data requester for target data. The data acquisition request includes a timestamp, a data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its own private key using the timestamp, the data identifier, and the public key.

[0008] If the timestamp and the public key indicate that the data requester is the second computing engine, the target data is returned to the second computing engine to execute the off-chain collaborative task generated by the off-chain computing contract. The second computing engine and the second blockchain node belong to the second node device.

[0009] According to a second aspect of one or more embodiments of this specification, another data processing method is proposed, applied to a second computing engine, wherein a second blockchain node is deployed in a second node device where the second computing engine is located, and an off-chain computing contract is deployed on the blockchain network to which the second blockchain node belongs; the method includes:

[0010] When the task event generated by the off-chain computing contract indicates that the first blockchain node and the second blockchain node are participants in the off-chain collaborative task, a data acquisition request for the target data is initiated to the first computing engine. The data acquisition request includes a timestamp, the data identifier of the target data, the public key of the second computing engine, and a signature generated by the second computing engine based on its own private key for the timestamp, the data identifier, and the public key. The first computing engine and the first blockchain node belong to the first node device.

[0011] Receive the target data returned by the first computing engine when the timestamp and the public key indicate that the initiator of the data acquisition request is the second computing engine;

[0012] The off-chain collaboration task is executed based on the target data.

[0013] According to a third aspect of one or more embodiments of this specification, a data processing apparatus is provided, applied to a first computing engine, wherein a first blockchain node is deployed in a first node device where the first computing engine is located, and an off-chain computing contract is deployed on the blockchain network to which the first blockchain node belongs; the apparatus includes:

[0014] A request receiving unit is used to receive a data acquisition request initiated by a data requester for target data. The data acquisition request includes a timestamp, a data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its own private key for the timestamp, the data identifier, and the public key.

[0015] The data return unit is used to return the target data to the second computing engine for executing the off-chain collaborative task generated by the off-chain computing contract, provided that the timestamp and the public key indicate that the data requester is the second computing engine. The second computing engine and the second blockchain node belong to the second node device.

[0016] According to a fourth aspect of one or more embodiments of this specification, another data processing apparatus is proposed, applied to a second computing engine, wherein a second blockchain node is deployed in a second node device where the second computing engine is located, and an off-chain computing contract is deployed on the blockchain network to which the second blockchain node belongs; the apparatus includes:

[0017] The request initiating unit is used to initiate a data acquisition request for target data to the first computing engine when the task event generated by the off-chain computing contract indicates that the first blockchain node and the second blockchain node are participants in the off-chain collaborative task. The data acquisition request includes a timestamp, the data identifier of the target data, the public key of the second computing engine, and a signature generated by the second computing engine based on its own private key for the timestamp, the data identifier, and the public key. The first computing engine and the first blockchain node belong to the first node device.

[0018] A data receiving unit is configured to receive the target data returned by the first computing engine when the timestamp and the public key indicate that the initiator of the data acquisition request is the second computing engine;

[0019] The task execution unit is used to execute the off-chain collaborative task based on the target data.

[0020] According to a fifth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0021] processor;

[0022] Memory used to store processor-executable instructions;

[0023] The processor implements the method as described in the first or second aspect by running the executable instructions.

[0024] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first or second aspect.

[0025] Through the technical solution of this specification, the first computing engine can receive a data acquisition request initiated by a data requester for target data. The request includes a timestamp, a data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its own private key for the timestamp, the data identifier, and the public key. If the timestamp and public key indicate that the data requester is the second computing engine (i.e., the request was initiated by the second computing engine), the first computing engine returns the target data to the second computing engine for executing the off-chain collaborative task.

[0026] Understandably, if a third party intercepts a data retrieval request initiated by the second computing engine and directly replays the request to the first computing engine, the request received by the first computing engine will be identical to the original request (with the same content). If the third party intercepts the data retrieval request initiated by the second computing engine, regenerates a signature using its own private key, and replays it to the first computing engine, this signature will be unverifiable by the first computing engine using the second computing engine. Furthermore, there may be a delay in the time it takes for the first computing engine to receive the replay request. Therefore, by introducing a timestamp variable into the data retrieval request, the first computing engine cannot conclude that the data requester is the second computing engine (i.e., the receiving computing engine was initiated by the second computing engine) based on the timestamp and signature in the replay request. This prevents the first computing engine from returning the target data to the third party in response to a replay request, thus eliminating the security risks that a third party's replay attack might pose. Attached Figure Description

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

[0028] Figure 1 This is a flowchart of a data processing method provided in an exemplary embodiment.

[0029] Figure 2 This is a flowchart of another data processing method provided in an exemplary embodiment.

[0030] Figure 3 This is an interactive flowchart of a data processing method provided in an exemplary embodiment.

[0031] Figure 4 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0032] Figure 5 This is a block diagram of an apparatus for a data processing method provided in an exemplary embodiment.

[0033] Figure 6 This is a block diagram of an apparatus for another data processing method provided in an exemplary embodiment. Detailed Implementation

[0034] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0035] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0036] In related technologies, requesters typically add their own signature to their data retrieval requests so that administrators can provide the required data only if the signature is verified. While this approach provides some access control over the retrieved data, it still struggles to prevent replay attacks: the requester's data retrieval request might be intercepted by a third party and resent to the administrator. Since the replay request still contains the requester's signature, it can still pass the administrator's verification and be processed normally, resulting in the data maintained by the administrator being exported to a third party, posing a significant security risk.

[0037] To address the aforementioned problems in related technologies, this specification proposes a data processing method in which a data requester initiates a data acquisition request containing a timestamp, data identifier, public key, and signature. A first computing engine then determines whether the request initiator is a second computing engine based on the timestamp and signature. The scheme is described in detail below with reference to the accompanying drawings.

[0038] Please see Figure 1 , Figure 1 This is a flowchart illustrating a data processing method provided in an exemplary embodiment. For example... Figure 1 As shown, the method is applied to a first computing engine, in which a first blockchain node is deployed in a first node device, and the blockchain network to which the first blockchain node belongs deploys an off-chain computing contract; the method includes steps 102-104.

[0039] Step 102: Receive a data acquisition request initiated by a data requester for target data. The data acquisition request includes a timestamp, a data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its own private key for the timestamp, the data identifier, and the public key.

[0040] For the multiple blockchain nodes included in the blockchain network, this specification's embodiments primarily focus on any two blockchain nodes, namely the first blockchain node and the second blockchain node. The node device deploying the first blockchain node (i.e., the node device where the first blockchain node resides) also deploys a first computing engine; similarly, the node device deploying the second blockchain node (i.e., the node device where the second blockchain node resides) also deploys a second computing engine. The aforementioned blockchain network deploys off-chain computing contracts. Each blockchain node in the network can execute these contracts to generate task events for off-chain collaborative tasks. For example, any blockchain node can invoke and execute the contract during the execution of a blockchain transaction to generate the task event. Correspondingly, the node device where any blockchain node resides can listen to the task events generated by that blockchain node. For example, the first node device can listen to the task events generated by the first blockchain node executing the aforementioned off-chain computing contract, and the second node device can listen to the task events generated by the second blockchain node executing the aforementioned off-chain computing contract.

[0041] In the embodiments described in this specification, an off-chain computing contract is an on-chain carrier used to perform off-chain computing tasks. The off-chain computing contract can define several sub-tasks included in an off-chain computing task to describe the data flow and computational collaboration process of each participant in the task. Since the off-chain computing contract is deployed on a blockchain network, the participants in the off-chain computing task defined by the contract are limited to the range of blockchain nodes within the network. Clearly, multiple off-chain computing contracts can be deployed on the same blockchain network, and the number and performance of the participating nodes involved in different contracts can be flexibly configured. This allows for the deployment of off-chain computing tasks of different types, requirements, and scales within the same blockchain network.

[0042] To illustrate how off-chain computing contracts guide the implementation of their defined off-chain computing tasks, the following section will briefly introduce the implementation logic of off-chain computing tasks through the operation process of a typical off-chain computing contract.

[0043] Users can generate off-chain computing contract code through a visual contract orchestration system and deploy off-chain computing contracts on the blockchain network. This allows them to define the workflow of a specific type of off-chain computing task within the contract, which is represented by several subtasks with execution dependencies. Once the off-chain computing contract is successfully deployed, users with the necessary permissions can create and initiate an off-chain computing task by sending a task creation transaction to the contract. After the task creation transaction, a task instance belonging to the initiating user is created. This task instance maintains the task completion status, specifically the completion status of each subtask within the off-chain computing task.

[0044] After the off-chain computation contract responds to the task creation transaction and generates the corresponding task instance, it further triggers the execution of the first subtask corresponding to that instance. This is reflected in the off-chain computation contract by generating a task event that indicates the participants in the first subtask. Each blockchain node in the blockchain network can listen to this task event, and the node devices of those blockchain nodes that determine themselves to be participants in the first subtask will further invoke the off-chain resources matching that first subtask to execute it off-chain. After execution, the node devices of participating blockchain nodes will further send a result return transaction carrying the execution result of the first subtask to the off-chain computation contract, thereby updating the task completion status of the corresponding task instance. For example, when the execution result of the first subtask is successful, the off-chain computation contract can mark the task completion status of the first subtask in the corresponding task instance as completed, thus triggering the execution of the next batch of subtasks according to the predefined dependency order of the subtasks included in the off-chain computation task. This generates an event containing the participating nodes of the next batch of subtasks for each blockchain node in the blockchain network to listen to, and the subsequent process is similar to the process of handling the first subtask described above. This creates a loop of "off-chain computing contract updates task completion status → off-chain computing contract generates subtask event → blockchain node listens for subtask event and the designated node device executes the subtask → node device sends a subtask result return transaction to off-chain computing contract → off-chain computing contract updates task completion status" until all subtasks in the task instance of the off-chain computing contract have a completed task status, at which point it can be determined that the off-chain computing task corresponding to that task instance has been completed.

[0045] It's easy to see that off-chain computing contracts are only used for scheduling tasks such as creating task instances, receiving subtask results, and scheduling and distributing subtasks during the execution of off-chain computing tasks. They don't actually perform the real tasks defined and required by the off-chain computing task, such as data computation, data transfer, and data storage. These resource-intensive tasks are scheduled to be executed by the off-chain computing engines deployed on various node devices. This achieves blockchain-based distributed computing through event listening and transaction feedback mechanisms, anchoring off-chain computing tasks to the off-chain computing contracts on the blockchain. This ensures full traceability of task execution while fully utilizing off-chain resources, and enables trusted information exchange and collaborative computing between different node devices via the blockchain. Furthermore, because off-chain computing tasks are defined in the form of contracts and their design is not constrained by on-chain resources, different off-chain computing contracts can be designed to meet different practical needs, thus expanding on-chain collaboration methods through off-chain resources.

[0046] In this embodiment, the off-chain computing contract maintains the task completion status corresponding to the off-chain computing task. The task completion status describes the completion status of each subtask included in the off-chain computing task. When an off-chain collaboration task is a subtask of the off-chain computing task, the task event can be generated by the off-chain computing contract when the task completion status meets the execution conditions of the off-chain collaboration task. The node device can listen to this task event through an event listening mechanism. In this embodiment, the task completion status of the off-chain computing task can be maintained in the corresponding task instance of the off-chain computing contract; specifically, the task instance can maintain the completion status of each subtask. Since the execution dependency order of each subtask included in the off-chain computing task is predefined, this means that the execution conditions of each subtask are also determined. Therefore, the off-chain computing contract can further determine the next off-chain collaboration task to be executed based on the completion status of each subtask, thereby initiating a task event for the off-chain collaboration task.

[0047] Furthermore, the node device executing the off-chain collaboration task can, upon completion of the task, initiate a result return transaction containing the execution result of the off-chain collaboration task to the off-chain computing contract through its own deployed blockchain node, thereby updating the task completion status of the off-chain computing task maintained by the off-chain computing contract. As mentioned earlier, when the node device executes the off-chain collaboration task by calling resources and completes the task, it can update the task completion status of the off-chain computing task maintained by the off-chain computing contract by initiating a result return transaction. This allows the off-chain computing contract to further determine the next sub-task to be executed based on the execution dependency order of each sub-task in the off-chain computing task and generate a task event for the next sub-task. In the embodiments of this specification, listening to the task events generated by the off-chain computing contract and initiating result return transactions to the off-chain computing contract can be accomplished by the scheduling framework deployed on the first node device.

[0048] As mentioned above, the task completion status is updated by the off-chain computing contract in response to the exchange corresponding to the off-chain computing task. The transaction corresponding to the off-chain computing task may include the task creation transaction corresponding to the off-chain computing task, or the result return transaction initiated by any node device after completing any of the sub-tasks.

[0049] As can be seen, the off-chain collaborative task described in the embodiments of this specification can be a special type of subtask among multiple subtasks included in an off-chain computing task. The special feature is that this off-chain collaborative task requires multiple participants to cooperate off-chain and complete the task execution through collaborative interaction. Of course, all subtasks included in an off-chain computing task can be the off-chain collaborative task; in this case, the embodiments of this specification only focus on the execution process of any one of the off-chain collaborative tasks. Alternatively, an off-chain computing task may contain only one off-chain collaborative task, and the embodiments of this specification do not impose any limitations on this.

[0050] In the embodiments described in this specification, the off-chain computing contract maintains the task completion status of one or more off-chain collaborative tasks. Typically, an off-chain computing contract defines only one type of off-chain collaborative task, but can create multiple task instances corresponding to that task. Each task instance records its corresponding task completion status. Therefore, the multiple task instances maintained on the off-chain computing contract can be triggered by different users initiating task creation contracts separately, or they can be triggered by the same user initiating multiple task creation contracts. However, these task instances all have the same execution logic, meaning that the task types of the tasks maintained by the off-chain computing contract are the same.

[0051] The first node device can also deploy a first scheduling framework corresponding to the first blockchain node, and the second node device can also deploy a second scheduling framework corresponding to the second blockchain node. As mentioned above, the specific process of the first node device and the second node device listening to the task events can be implemented by the first scheduling framework and the second scheduling framework, respectively; that is, the first scheduling framework and the second scheduling framework can listen to the task events separately. Based on this, the first scheduling framework can distribute the off-chain collaborative task to the first computing engine for execution according to the listened task events; similarly, the second scheduling framework can distribute the off-chain collaborative task to the second computing engine for execution according to the listened task events. Through this method, the distribution process of off-chain collaborative tasks is completed by the scheduling framework without the participation of node devices or blockchain nodes, realizing the independence of the task distribution process and facilitating efficient distribution in multi-task scenarios.

[0052] The scheduling framework can distribute tasks based on the task type of the off-chain collaborative task. For example, the second scheduling framework can first determine the task type of the off-chain collaborative task and the computation type of the second computing engine, and then distribute the off-chain collaborative task to the second computing engine if the computation type matches the task type. Specifically, when multiple computing engines are deployed in the second node device, the second scheduling framework can sequentially determine the computation type of each second computing engine, then determine at least one second computing engine whose computation type matches the task type, further select a second target computing engine, and then distribute the off-chain collaborative task to that second target computing engine for execution. Similarly, the first scheduling framework can first determine the task type of the off-chain collaborative task and the computation type of the first computing engine, and then distribute the off-chain collaborative task to the first computing engine if the computation type matches the task type. Specifically, when multiple computing engines are deployed in the first node device, the first scheduling framework can sequentially determine the computing type of each first computing engine, then determine at least one first computing engine from among the second computing engines whose computing type matches the task type, and further select a first target computing engine from among them, and then distribute the off-chain collaborative task to the first target computing engine for execution. The aforementioned computing type and task type can be forwarding type, MFT (Managed File Transfer) type, privacy computing type, data query type, etc., and the embodiments in this specification do not limit this. In this way, the scheduling framework can allocate off-chain collaborative tasks to computing engines of the corresponding type, which helps to achieve the smooth and efficient execution of off-chain collaborative tasks.

[0053] In addition to issuing the off-chain collaboration task to the first computing engine, the first node device can also forward the task event to the first computing engine upon detecting it. Both the off-chain collaboration task and the task event can be used to indicate the participants in the off-chain collaboration task and the target data required to execute it. For example, the off-chain collaboration task or task event can record the public keys and other identity information of the participants, as well as the data identifier of the target data. Therefore, by receiving the off-chain collaboration task or task event sent by the first node device, the first computing engine can obtain the data identifier of the target data, the public key of the second computing engine, and other information.

[0054] Upon detecting the aforementioned task event, the second node device can determine the participants in the off-chain collaboration task based on the event. For example, if the description information includes the identifier of a blockchain node, the second node device can determine that the blockchain node is a participant in the off-chain collaboration task. Taking the second blockchain node as an example, if the description information includes the identifier of the second blockchain node, the second node device can determine that the second blockchain node is a participant in the off-chain collaboration task, and thus the second node device needs to start processing the off-chain collaboration task. However, if the description information does not include the identifier of the second blockchain node, the second node device can determine that the second blockchain node is not a participant in the off-chain collaboration task, and thus the second node device will not process the off-chain collaboration task. In fact, the aforementioned task event can also record task information such as the source of data that needs to be transferred between the participants for the task type of the off-chain collaboration task (i.e., the computing engine used to store the target data required to execute the off-chain collaboration task). This task information is used to inform each node device of the task type and its implementation method of the off-chain collaboration task, thereby guiding the node device to execute the task as expected after determining the available resources. Based on the above description, it can be determined whether the second blockchain node and the first blockchain node are participants in the off-chain collaborative task; based on the above task information, it can be further determined whether the second blockchain node and the first blockchain node are respectively the manager and the requester of the target data; in other words, the task event can be used to indicate whether the second blockchain node and the first blockchain node are participants in the off-chain collaborative task and whether they are respectively the manager and the requester of the target data.

[0055] In addition, task events can also record task identifiers for off-chain computing tasks and off-chain collaboration tasks, thereby distinguishing different tasks and subtasks. This is mainly to facilitate subsequent node devices to correctly identify the result of the off-chain collaboration task in the off-chain computing task when the off-chain collaboration task is completed and the result is returned as a transaction. This allows the off-chain computing contract to correctly update the completion status of the off-chain collaboration task in the corresponding off-chain computing task instance through the result return transaction, in order to deal with situations where the same task contains multiple subtasks or the same off-chain computing annual contract creates multiple off-chain computing task instances at the same time.

[0056] When the task event indicates that the first blockchain node and the second blockchain node are participants in the off-chain collaborative task, the second computing engine can initiate a data acquisition request for the target data to the first computing engine. For example, if the second computing engine determines that it needs to acquire the target data from the first computing engine based on the task event or the off-chain collaborative task, it can determine a timestamp, generate a signature using its private key for the timestamp, the data identifier of the target data, and its own public key, and then initiate a data acquisition request to the first computing engine containing the aforementioned timestamp, data identifier, public key, and signature. This data acquisition request is used to request the target data from the first computing engine.

[0057] Step 102: If the timestamp and the public key indicate that the data requester is the second computing engine, the target data is returned to the second computing engine to execute the off-chain collaborative task generated by the off-chain computing contract. The second computing engine and the second blockchain node belong to the second node device.

[0058] The data acquisition request initiated by the second computing engine may be intercepted by a third party and replayed in the aforementioned manner. In order to ensure that only the data acquisition request initiated by the second computing engine is processed and the replay request is not processed, the first computing engine, as the request recipient, can judge the received data acquisition request. If the timestamp and the public key indicate that the data requester is the second computing engine (that is, it is determined that the received data acquisition request was indeed initiated by the second computing engine), the target data can be returned to the second computing engine for executing the off-chain collaborative task.

[0059] Through the above scheme, the first computing engine can receive a data acquisition request initiated by a data requester for target data. The request includes a timestamp, a data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its own private key for the timestamp, the data identifier, and the public key. If the timestamp and public key indicate that the data requester is the second computing engine (i.e., the request was initiated by the second computing engine), the first computing engine returns the target data to the second computing engine for executing the off-chain collaborative task.

[0060] Understandably, if a third party intercepts a data retrieval request initiated by the second computing engine and directly replays the request to the first computing engine, the request received by the first computing engine will be identical to the original request (with the same content). If the third party intercepts the data retrieval request initiated by the second computing engine, regenerates a signature using its own private key, and replays it to the first computing engine, this signature will be unverifiable by the first computing engine using the second computing engine. Furthermore, there may be a delay in the time it takes for the first computing engine to receive the replay request. Therefore, by introducing a timestamp variable into the data retrieval request, the first computing engine cannot conclude that the data requester is the second computing engine (i.e., the received request was initiated by the second computing engine) based on the timestamp and signature in the replay request. This prevents the first computing engine from returning the target data to the third party in response to a replay request, thus eliminating the security risks that a third party's replay attack might pose.

[0061] Upon receiving the data acquisition request, in order to identify whether the signature contained in the data acquisition request was generated by the second computing engine, the first computing engine can use the public key of the second computing engine obtained in the aforementioned manner to verify the signature: if the verification is successful, it can be determined that the signature was generated based on the private key of the second computing engine, in other words, it can be determined that the signature was generated by the second computing engine; conversely, if the verification fails, it can be determined that the signature was not generated by the second computing engine. On the other hand, to determine whether the data retrieval request is a replay request, the cache can be queried to see if there are any valid historical requests. These historical requests should include the timestamp, the data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its private key using the timestamp, the data identifier, and the public key. In other words, the cache can be queried to see if there is a historical request that is exactly the same as the received data retrieval request. If the historical request exists in the cache (in fact, the content of the historical request is exactly the same as the received data retrieval request), it indicates that the historical request is being processed but has not yet been completed. Therefore, the processing of the newly received data retrieval request can be terminated, and the processing of the historical request can continue. Conversely, if the aforementioned historical request does not exist in the cache, it indicates that the request has not yet been processed. In this case, the processing of the data retrieval request can be triggered, and the request can be recorded in the cache or set to a valid state in the cache.

[0062] As can be seen, if the signature in the data acquisition request is verified by the public key of the second computing engine, and there is no historical request in the cache of the first computing engine that is in a valid state with the same data acquisition request, then the timestamp and the public key indicate that the data requester is the second computing engine, and the target data can be returned to the second computing engine. If the signature in the data acquisition request is not verified by the public key of the second computing engine, or there is a historical request in the cache of the first computing engine that is in a valid state with the same data acquisition request, then the timestamp and the public key indicate that the data requester is not the second computing engine, i.e., the request is a replay request, and the return of the target data to the second computing engine can be refused. In other words, if the timestamp and the public key indicate that the data requester is not the second computing engine, the first computing engine can refuse to return the target data to the second computing engine. In this way, the first computing engine can identify both data acquisition requests directly replayed by a third party and data acquisition requests generated and replayed by a third party using its own signature, thereby effectively solving the security risks that may be caused by the replay of data acquisition requests.

[0063] Furthermore, if the data requester is determined to be the second computing engine, the first computing engine can record the received data retrieval request in the cache; alternatively, it can set the data retrieval request to a valid state in the cache. For example, the first computing engine can record the data retrieval request in a request list it maintains. This request list records data retrieval requests received by the first computing engine that have not yet been processed (i.e., the corresponding data has not yet been returned to the requester). In this way, the first computing engine can record the correspondence between the data retrieval request and its contained timestamp, data identifier, public key, and signature. This correspondence can be queried when a new data retrieval request is received subsequently to determine whether the request is being processed, thereby avoiding duplicate processing of the same request.

[0064] Accordingly, in order to ensure that the second computing engine can continue to respond to other data acquisition requests for the target data after the request is processed, and to reduce the invalid occupation of cache space by the above invalid requests, the first computing engine may delete the data acquisition request recorded in the cache or update the data acquisition request to an invalid state in the cache if the current time exceeds the time interval corresponding to the timestamp or if it is determined that the target data has been successfully returned to the second computing engine.

[0065] The timestamp can be the moment when the second computing engine generates or initiates the data acquisition request, and the time interval can be a period of time including that moment. For example, since the clock times of the first and second computing engines may not be consistent (e.g., the clock time of the first computing engine may be earlier than the clock time of the second computing engine), the start time of the time interval can be a first duration before the timestamp—even if the clock time of the data acquisition request received by the first computing engine is earlier than the clock time when the second computing engine initiates the data acquisition request, as long as the difference between the two clock times is not greater than the first duration, the first computing engine can still process the request normally. As another example, since the sending and receiving process of the data acquisition request inevitably consumes a certain amount of time, the end time of the time interval can be a second duration after the timestamp—even if the clock time of the data acquisition request received by the first computing engine is later than the clock time when the second computing engine initiates the data acquisition request, as long as the difference between the two clock times is not greater than the second duration, the first computing engine can still process the request normally. Furthermore, the specific values ​​of the first and second durations mentioned above can be reasonably set according to actual conditions such as network latency, the current data volume of the direct connection channel, and the data volume of the data acquisition request. This embodiment of the specification does not impose any limitations on this. In this way, the first computing engine can process data acquisition requests received within a reasonable time range as much as possible, thereby improving the success rate of the second computing engine in acquiring the target data to a certain extent.

[0066] In one embodiment, to ensure that target data can only be obtained by relevant parties with the corresponding permissions, the first computing engine can first determine whether the second computing engine has the permission to obtain the target data, and if it is determined that the second computing engine has the permission, then return the target data to the second computing engine. The first computing engine can maintain an authorization list for the target data, which records the identity information of each party authorized to obtain the target data. For example, the first computing engine can determine the identity information of each legitimate party authorized to obtain the target data based on the aforementioned task event or other off-chain methods. Furthermore, the first computing engine can record the determined identity information in the authorization list, and if it is determined that any party no longer has the permission, it can delete the corresponding identity information from the list. Alternatively, the first computing engine can record the determined identity information in the authorization list and set it to an authorized state, and if it is determined that any party no longer has the permission, it can update the corresponding identity information in the list to an unauthorized state.

[0067] Based on the authorization list, the first computing engine can query the identity information or authorization status of the second computing engine in the list. If the first engine determines that the second computing engine's identity information exists in the list or that the identity information is in an authorized state, the first engine determines that the second computing engine has the permission to obtain the target data. In this way, the first computing engine will only generate the token so that the second computing engine can use it to obtain the target data if it is determined that the second computing engine has the permission. This strengthens the access control over the recipient of the target data and the process of outputting the target data, thereby improving the security of the target data to some extent.

[0068] In another embodiment, considering the potential delays or errors in deleting historical requests recorded in the cache, if the data retrieval request is initiated by the second computing engine, the first computing engine can further determine whether the current moment falls within the time interval corresponding to the timestamp: if the current moment falls within this time interval, the first computing engine can return the target data to the second computing engine; if the current moment has exceeded this time interval, the first computing engine can refuse to return the target data to the second computing engine, thus terminating the processing of the data retrieval request. It is understood that setting the aforementioned time interval for the timestamp effectively sets a processing time window (i.e., validity period) for the data retrieval request—any data retrieval request exceeding this time window will no longer be responded to, thus avoiding potential security risks caused by replay or processing timeouts.

[0069] As seen in the foregoing embodiments, to execute off-chain collaborative tasks, the first computing engine and the second computing engine need to interact. For example, the second computing engine may initiate a data acquisition request to the first computing engine, or the first computing engine may return target data to the second computing engine. This interaction can be achieved through a consensus link between the first and second blockchain nodes. For instance, the second computing engine can submit the data acquisition request to a second node device, which then sends the request to the first node device via the consensus link. The first node device can then forward the request to the first computing engine. Similarly, the first computing engine can submit the target data to the first node device, which returns the request to the second node device via the same consensus link. The second node device can then forward the request to the second computing engine. This consensus link serves as a path for transaction consensus or on-chain data transmission between the first and second blockchain nodes. This method allows for the reuse of the consensus link, thereby improving its utilization. In addition, the first node device can deploy the first P2P component corresponding to the first blockchain node, and the second node device can deploy the second P2P component corresponding to the second blockchain node. The consensus link between the first blockchain node and the second blockchain node can be the consensus link between the first P2P component and the second P2P component, which will not be elaborated further.

[0070] Furthermore, to avoid potential transmission failures or interference with existing on-chain processes such as transaction consensus during target data transmission via the consensus link, a direct connection channel can be established between the first and second computing engines through this consensus link. This direct connection channel enables the interaction between the first and second computing engines as described in this embodiment. For example, if the task event detected by the first node indicates that the first and second blockchain nodes are participants in the off-chain collaborative task, the first node device can send the first address information of the first computing engine to the second node device where the second blockchain node is located via the consensus link. Correspondingly, the second computing engine deployed on the second node device can establish a direct connection channel with the first computing engine based on the first address information. Similarly, the direct connection channel can also be established by the second node device sending the second address information of the second computing engine to the first node device where the first blockchain node is located via the consensus link if the task event detected by the second node indicates that the first and second blockchain nodes are participants in the off-chain collaborative task. Correspondingly, the first computing engine deployed on the first node device can establish a direct connection channel with the second computing engine based on the second address information.

[0071] The address information mentioned above can be the network address information such as the IP address and port number of the corresponding computing engine, which is used to accurately inform other computing engines of the network address of the computing engine, so as to facilitate the establishment of a direct connection channel in the future; it can also include identity information such as proxy address and engine identifier, which is used to accurately inform other computing engines of the identity of the computing engine, so as to facilitate other computing engines to manage the direct connection channel they have established and the various computing engines connected to it in an orderly manner.

[0072] It is understandable that if the second computing engine establishes a direct connection with the first computing engine based on address information, and the first computing engine also establishes a direct connection with the second computing engine based on address information, then the two direct connections should be completely identical after successful establishment—the only difference being the initiator of the establishment process. Therefore, to simplify the connection between computing engines and facilitate the maintenance and management of direct connections, it is unnecessary to simultaneously establish the aforementioned two direct connections between the second and second computing engines. Therefore, when the task event indicates that the first and second blockchain nodes are participants in the off-chain collaborative task, the second node device can send the second address information of the second computing engine to the first node device through the consensus link. If the second computing engine receives a channel establishment request initiated by the first computing engine based on the second address information before the aforementioned direct connection (i.e., the direct connection established by the second computing engine with the first computing engine based on the first address information) has been established, it can establish the direct connection by returning a channel establishment response to the first computing engine. Of course, once the direct connection is successfully established, the first computing engine and the second computing engine can refuse to establish another direct connection between them, thereby avoiding the repeated establishment of the direct connection and simplifying the network structure of the off-chain interaction network between computing engines as much as possible while meeting the needs of collaborative interaction.

[0073] After the direct connection channel is established, the first computing engine and the second computing engine can interact collaboratively through this channel when executing the off-chain collaborative tasks. For example, the first computing engine can receive the data acquisition request initiated by the second computing engine through the direct connection channel; and / or, the first computing engine can return target data to itself through the direct connection channel. In this way, the first and second computing engines can interact collaboratively through the direct connection channel established between them, such as initiating requests or returning target data. This method only needs to use the consensus link to transmit address information with a small amount of data, which avoids interference with the original on-chain process based on the consensus link to a certain extent. Furthermore, since the direct connection channel is only used for data transmission between the second and second computing engines, the possibility of errors in target data transmission is also reduced.

[0074] In the above, as Figure 1The illustrated embodiment describes the process of transmitting target data in this specification from the perspective of the first computing engine. The following will be combined with... Figure 2 This specification describes the technical solution from the perspective of the second computing engine. It is easy to understand that... Figure 2 The illustrated embodiments and Figure 1 The embodiments shown are not fundamentally different, as previously stated... Figure 1 The descriptions of the embodiments shown are all applicable to Figure 2 The example shown.

[0075] Please see Figure 2 , Figure 2 This is a flowchart illustrating another data processing method provided in an exemplary embodiment. For example... Figure 2 As shown, the method is applied to a second computing engine, in which a second blockchain node is deployed in a second node device, and the blockchain network to which the second blockchain node belongs deploys an off-chain computing contract; the method includes steps 202-206.

[0076] Step 202: If the task event generated by the off-chain computing contract indicates that the first blockchain node and the second blockchain node are participants in the off-chain collaborative task, a data acquisition request for the target data is initiated to the first computing engine. The data acquisition request includes a timestamp, the data identifier of the target data, the public key of the second computing engine, and a signature generated by the second computing engine based on its own private key for the timestamp, the data identifier, and the public key. The first computing engine and the first blockchain node belong to the first node device.

[0077] Step 204: Receive the target data returned by the first computing engine when the timestamp and the public key indicate that the initiator of the data acquisition request is the second computing engine.

[0078] Step 206: Execute the off-chain collaboration task based on the target data.

[0079] As mentioned above, the second node device may also deploy a second scheduling framework, allowing the second computing engine to receive the off-chain collaborative task distributed to the first computing engine by the second scheduling framework in response to the detected task event. Specifically, the off-chain collaborative task may be distributed to the second computing engine by the second scheduling framework if the computing type of the second computing engine matches the task type of the off-chain collaborative task.

[0080] As mentioned above, the off-chain collaborative task is distributed to the second computing engine by the second scheduling framework when the computing type of the second computing engine matches the task type of the off-chain collaborative task.

[0081] In one embodiment, the second computing engine can execute the off-chain collaboration task itself; or, if the second computing engine allows the invocation of other remote computing engines (such as a proxy computing engine deployed in the second node device), the second computing engine can invoke the aforementioned remote computing engine to execute the off-chain collaboration task. Similarly, the first computing engine can also execute the off-chain collaboration task itself or by invoking a corresponding remote computing engine, which will not be elaborated further.

[0082] The second computing engine can execute the off-chain collaboration task and obtain the corresponding execution result. Afterward, the second computing engine can return the execution result to the second blockchain node. For example, the second computing engine can return the execution result of the off-chain collaboration task to the second scheduling framework, which then uploads the execution result to the second blockchain node. Alternatively, the execution result can be returned to the task instance generated for the off-chain collaboration task in the second blockchain node, thus completing the full processing of the off-chain collaboration task. Furthermore, if the off-chain collaboration task is any sub-task of an off-chain computing task, the second blockchain node can also update the task completion status of the off-chain computing task based on the execution result. For example, it can update the completion status of this seed task to "completed," thereby triggering the off-chain computing task to advance its corresponding workflow, such as triggering the execution of the next sub-task.

[0083] For details of the various embodiments corresponding to the second computing engine, please refer to the description of the embodiments of the first computing engine mentioned above, which will not be repeated here.

[0084] In one embodiment, the second computing engine can return the execution result of the off-chain collaborative task to the second computing node through the second node device; or, if the off-chain collaborative task is distributed to the second computing engine by the second scheduling framework corresponding to the second blockchain node, the execution result of the off-chain collaborative task can be returned to the second computing node through the second scheduling framework.

[0085] Understandably, if a third party intercepts a data retrieval request initiated by the second computing engine and directly replays the request to the first computing engine, the request received by the first computing engine will be identical to the original request (with the same content). If the third party intercepts the data retrieval request initiated by the second computing engine, regenerates a signature using its own private key, and replays it to the first computing engine, this signature will be unverifiable by the first computing engine using the second computing engine. Furthermore, there may be a delay in the time it takes for the first computing engine to receive the replay request. Therefore, by introducing a timestamp variable into the data retrieval request, the first computing engine cannot conclude that the data requester is the second computing engine (i.e., the receiving computing engine was initiated by the second computing engine) based on the timestamp and signature in the replay request. This prevents the first computing engine from returning the target data to the third party in response to a replay request, thus eliminating the security risks that a third party's replay attack might pose.

[0086] Please see Figure 3 , Figure 3 This is an interactive flowchart of a data processing method provided in an exemplary embodiment. For example... Figure 3 As shown, the method includes steps 301a-311.

[0087] Step 301a: The second computing engine obtains the task events or off-chain collaborative tasks listened to by the second node device.

[0088] Step 301b: The first computing engine obtains the task events or off-chain collaborative tasks listened to by the first node device.

[0089] During the process of a blockchain node in a blockchain network invoking and executing an off-chain computation contract, this contract can generate task events for off-chain collaborative tasks. The node devices of each blockchain node in the computation engine can listen to these task events. Specifically, a first node device can send the task event or the off-chain collaborative task to a first computation engine if the task event indicates that the first blockchain node is a participant in the off-chain collaborative task; similarly, a second node device can send the task event or the off-chain collaborative task to a second computation engine if the task event indicates that the second blockchain node is a participant in the off-chain collaborative task. The listening process for these task events can be handled by a scheduling framework deployed on each node device.

[0090] In addition to specifying the identities of the participants in the off-chain collaboration task, the aforementioned task events or off-chain collaboration tasks can also specify the target data required to execute the off-chain collaboration task, as well as the data manager and data requester corresponding to that data. The following example illustrates the process by which the second computing engine requests the target data from the first computing engine and executes the off-chain collaboration task, using the first computing engine as the data manager and the second computing engine as the data requester.

[0091] Step 302: The second computing engine uses its own private key to generate a second signature using the timestamp, the data identifier of the target data, and the public key of the second computing engine.

[0092] Step 303: The second computing engine sends a data acquisition request to the first computing engine, which includes the timestamp, the data identifier, the public key, and the second signature.

[0093] When the second computing engine determines that it needs to obtain target data from the first computing engine based on the task event, it can determine a timestamp, such as using the current time as the timestamp, and generate a signature using its own private key, the data identifier of the target data, and the public key of the second computing engine. The identifier of the target data can be obtained from the task event; the public key of the second computing engine can be obtained locally (the second computing engine maintains its own public key locally), or it can be obtained from the task event, but this embodiment does not limit this.

[0094] Furthermore, upon generating the aforementioned signature, the second computing engine can initiate a data retrieval request to the first computing engine, which includes the timestamp, the data identifier, the public key, and the signature.

[0095] Step 304: The first computing engine uses the second computing engine to verify the signature recorded in the data acquisition request, and queries the request in each historical request in the cache record.

[0096] Upon receiving the token acquisition request, the first computing engine needs to determine whether the request is valid. On one hand, the first computing engine can use the public key of the second computing engine contained in the task event to verify the signature included in the data acquisition request. If the verification passes, it indicates that the signature in the request was indeed generated by the second computing engine using its own private key. Therefore, the timestamp, data identifier, and public key carried in the request correspond to the private key that generated the signature, thus confirming that the initiator of the request is indeed the second computing engine. Otherwise, if the verification fails, it indicates that the request is a fake request, and processing of the request can be terminated. On the other hand, the first data acquisition request can query its own maintained request list to see if it has been received. This request list records data acquisition requests received by the first computing engine but not yet processed. If the data acquisition request exists in the list, it indicates that the first computing engine has previously received the request but has not yet processed it, so processing of the data acquisition request can be terminated to avoid duplicate processing of the same request. If the data acquisition request does not exist in the list, the request can be recorded in the request list, and a response to the request can be triggered.

[0097] Step 305: The first calculation engine verifies whether the current moment is within the time interval corresponding to the timestamp.

[0098] Furthermore, since the clock times of the first and second computing engines may not be synchronized, the current time after the first computing engine receives the data acquisition request may have exceeded the time interval corresponding to the timestamp. For example, the current time may be earlier than the start time or later than the end time of the time interval. Additionally, since the sending and receiving of data acquisition requests inevitably takes some time, the current time may be later than the end time of the time interval. If the current time is not within the time interval corresponding to the timestamp, the first computing engine may refuse to process the data acquisition request; it will only continue to process the request if the current time is within the time interval corresponding to the timestamp. Enabling the first computing engine to process data acquisition requests received within a reasonable time range as much as possible not only helps improve the effectiveness of access control over target data but also, to some extent, increases the success rate of the second computing engine in acquiring target data.

[0099] Step 306: The first computing engine verifies the second computing engine's access permission to the target data.

[0100] The first computing engine needs to determine whether the second computing engine that initiated the request is a legitimate recipient of the target data. For example, the first computing engine can query the public key of the second computing engine in the locally maintained list of authorized accesses for the target data. If the public key of the second computing engine exists in the list of authorized accesses, it indicates that the second computing engine does have the right to access the target data, and the request can be processed normally. Otherwise, if the public key of the second computing engine does not exist in the list of authorized accesses, it indicates that the second computing engine does not have the right to access the target data, and the request can be terminated.

[0101] It is worth noting that the embodiments in this specification do not impose any restrictions on the order of the aforementioned verification processes, and adjustments can be made according to the actual situation.

[0102] Step 307: The first computing engine records the data retrieval request in the cache.

[0103] If the aforementioned verification passes, the first computing engine can record the data retrieval request in the cache. Alternatively, as described in step 304, if it is determined that the data retrieval request does not exist in the cache, the request can be recorded in the request list, which will not be elaborated further.

[0104] Step 308: The first computing engine returns the target data to the second computing engine.

[0105] The first computing engine can return the target data through the consensus link between the first blockchain node and the second off-chain computing contract, using the first node device and the second node device.

[0106] Alternatively, the first node device and the second node device can also transmit the address information of the first computing engine or the second computing engine to each other based on the consensus link, so as to establish a direct connection channel between the first computing engine and the second computing engine. This allows the first computing engine to return the target data to the second computing engine via this direct connection channel. The specific process of establishing the direct connection channel can be found in the description of the foregoing embodiments, and will not be repeated here. It should also be noted that the first computing engine and the second computing engine can achieve collaborative interaction through the direct connection channel established between them. For example, the first computing engine can receive the data acquisition request initiated by the second computing engine through the direct connection channel; and / or, the first computing engine can return the target data to itself through the direct connection channel. This method only requires the use of the consensus link to transmit address information with a small data volume, which to some extent avoids interference with the original on-chain processes based on the consensus link. Furthermore, since the direct connection channel is only used for data transmission between the second computing engine and the second computing engine, the possibility of errors in the target data transmission is also reduced.

[0107] Step 309: The first computing engine clears the data retrieval requests recorded in the cache.

[0108] If it is determined that the current time exceeds the time interval corresponding to the timestamp, or if it is determined that the target data has been successfully returned to the second computing engine, the first computing engine can clear the data retrieval request recorded in the cache to achieve one-time processing of the request and save cache space. Specifically, to better identify replay requests for data retrieval, the time interval corresponding to the timestamp can be appropriately extended, thereby achieving better identification and handling of replay requests.

[0109] Step 310: The second computing engine uses the target data to perform an off-chain collaborative task.

[0110] Upon receiving the target data returned by the first computing engine, the second computing engine can execute the off-chain collaboration task independently; alternatively, if the second computing engine allows the invocation of other remote computing engines (such as a proxy computing engine deployed in the second node device), the second computing engine can invoke the aforementioned remote computing engine to execute the off-chain collaboration task. Similarly, the first computing engine can also execute the off-chain collaboration task independently or by invoking a corresponding remote computing engine, which will not be elaborated further.

[0111] Step 311: The second computing engine returns the execution result of the off-chain collaborative task to the second blockchain node.

[0112] The second computing engine can return the execution result of the off-chain collaborative task to the second blockchain node. For example, the second computing engine can return the execution result of the off-chain collaborative task to the second scheduling framework, which then uploads the execution result to the second blockchain node. This could involve returning the execution result to the task instance generated for the off-chain collaborative task within the second blockchain node, thus completing the full processing of the off-chain collaborative task. Furthermore, if the off-chain collaborative task is any subtask of an off-chain computing task, the second blockchain node can also update the task completion status of the off-chain computing task based on the execution result. For example, it can update the completion status of this seed task to "completed," thereby triggering the off-chain computing task to advance its corresponding workflow, such as triggering the execution of the next subtask.

[0113] Figure 4 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 4At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 402 reading the corresponding computer program from the non-volatile memory 410 into memory 408 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 hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0114] like Figure 5 As shown, Figure 5 This is a block diagram of a data processing apparatus provided in this specification according to an exemplary embodiment, which can be applied to, for example... Figure 4 The device shown is used to implement the technical solution of this specification. This device is applied to a first computing engine, and a first blockchain node is deployed in the first node device where the first computing engine is located. The blockchain network to which the first blockchain node belongs deploys off-chain computing contracts. The device includes:

[0115] The request receiving unit 501 is used to receive a data acquisition request initiated by a data requester for target data. The data acquisition request includes a timestamp, a data identifier of the target data, the public key of the data requester, and a signature generated by the data requester based on its own private key for the timestamp, the data identifier, and the public key.

[0116] The data return unit 502 is used to return the target data to the second computing engine for executing the off-chain collaborative task generated by the off-chain computing contract when the timestamp and the public key indicate that the data requester is the second computing engine. The second computing engine and the second blockchain node belong to the second node device.

[0117] Optionally, the off-chain computing contract maintains the task completion status of the off-chain computing task, which describes the completion status of each subtask included in the off-chain computing task; when the off-chain collaboration task is a subtask of the off-chain computing task, the task event is generated by the off-chain computing contract when the task completion status meets the execution conditions of the off-chain collaboration task.

[0118] Optionally, the task completion status is updated by the off-chain computing contract in response to the transaction corresponding to the off-chain computing task, wherein the transaction corresponding to the off-chain computing task includes the task creation transaction corresponding to the off-chain computing task, or the result return transaction initiated by any node device after completing any of the sub-tasks.

[0119] Optionally, the data return unit 502 is further configured to:

[0120] If the signature is verified by the public key of the second computing engine, and there is no valid historical request in the cache of the first computing engine that is in the same state as the data acquisition request, then the timestamp and the public key indicate that the data requester is the second computing engine.

[0121] Optional, also includes:

[0122] The cache recording unit 503 is configured to, when the timestamp and the public key indicate that the data requester is a second computing engine, record the data acquisition request in the cache or set the data acquisition request to a valid state in the cache; and...

[0123] The cache clearing unit 504 is used to delete the data acquisition request recorded in the cache or update the data acquisition request to an invalid state in the cache when the current time exceeds the time interval corresponding to the timestamp or when it is determined that the target data has been successfully returned to the second computing engine.

[0124] Optionally, the data return unit 502 is further configured to:

[0125] If the second computing engine has permission to access the target data, and / or if the current state is such that the target data is returned to the second computing engine.

[0126] Optionally, the first computing engine maintains an authorization list, which records the identity information of each party authorized to obtain the target data. The data return unit 502 is further used for:

[0127] If the public key of the second computing engine is recorded in the authorization list or the public key is in a valid state, it is determined that the second computing engine has the right to obtain the target data.

[0128] Optionally, the timestamp is spaced from the start time of the time interval by a first duration and from the end time of the time interval by a second duration.

[0129] Optional, also includes:

[0130] The rejection return unit 505 is used to refuse to return the target data to the second computing engine if the timestamp and the public key indicate that the data requester is not the second computing engine.

[0131] Optionally, the data return unit 502 is further configured to:

[0132] The target data is returned to the second computing engine via a consensus link between the first and second blockchain nodes; or...

[0133] The target data is returned to the second computing engine through a direct connection between the first and second computing engines.

[0134] Optionally, a channel establishment unit 506 is also included, for:

[0135] The first node device receives the address information of the second computing engine forwarded by the first node device, and establishes the direct connection channel with the second computing engine according to the address information. The address information is sent by the second node device to the first node device through the consensus link between the first blockchain node and the second blockchain node when the task event indicates that the first blockchain node and the second blockchain node are participants in the off-chain collaborative task.

[0136] Optionally, the public key of the second computing engine includes the node public key of the second blockchain node.

[0137] like Figure 6 As shown, Figure 6 This is a block diagram of another data processing apparatus provided in this specification according to an exemplary embodiment, which can be applied to, for example... Figure 4 The device shown implements the technical solution described in this specification. This device is applied to a second computing engine, and a second blockchain node is deployed in the second node device where the second computing engine is located. The blockchain network to which the second blockchain node belongs deploys off-chain computing contracts. The device includes:

[0138] The request initiating unit 601 is used to initiate a data acquisition request for target data to the first computing engine when the task event generated by the off-chain computing contract indicates that the first blockchain node and the second blockchain node are participants in the off-chain collaborative task. The data acquisition request includes a timestamp, a data identifier of the target data, a public key of the second computing engine, and a signature generated by the second computing engine based on its own private key for the timestamp, the data identifier, and the public key. The first computing engine and the first blockchain node belong to the first node device.

[0139] Data receiving unit 602 is used to receive the target data returned by the first computing engine when the timestamp and the public key indicate that the initiator of the data acquisition request is the second computing engine;

[0140] The task execution unit 603 is used to execute the off-chain collaborative task based on the target data.

[0141] Optionally, the second node device also deploys a second scheduling framework, and the device further includes a task acquisition unit 604, used for:

[0142] The off-chain collaborative task is received by the second scheduling framework in response to the listened-upon task event and distributed to the first computing engine.

[0143] Optionally, the off-chain collaborative task is distributed to the second computing engine by the second scheduling framework if the computing type of the second computing engine matches the task type of the off-chain collaborative task.

[0144] Optionally, the task execution unit 603 is further configured to:

[0145] The second computing engine itself executes the off-chain collaborative task; or...

[0146] The second computing engine invokes the remote computing engine to execute the off-chain collaborative task.

[0147] Optional, also includes:

[0148] The first return unit 605 is used to return the execution result of the off-chain collaborative task to the second computing node via the second node device; or,

[0149] The second return unit 606 is used to return the execution result of the off-chain collaborative task to the second computing node through the second scheduling framework when the off-chain collaborative task is distributed to the second computing engine by the second scheduling framework corresponding to the second blockchain node.

[0150] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0151] The controller can be implemented in any suitable manner. For example, it 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 Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0153] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0154] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0155] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0156] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0157] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0159] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0160] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0161] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. 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, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0162] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0163] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0164] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A data processing method applied to a first computing engine, wherein a first blockchain node is deployed in a first node device where the first computing engine is located, and an off-chain computing contract is deployed in the blockchain network to which the first blockchain node belongs, the off-chain computing contract maintaining the task completion status of an off-chain computing task, the task completion status describing the completion status of each sub-task included in the off-chain computing task; the method comprising: The system receives a data acquisition request initiated by a requester for target data. The data acquisition request includes a timestamp, a data identifier of the target data, the requester's public key, and a signature generated by the requester based on its own private key using the timestamp, the data identifier, and the public key. If the timestamp and the public key indicate that the requester is the second computing engine, the target data is returned to the second computing engine to execute the off-chain collaboration task generated by the off-chain computing contract. The second computing engine and the second blockchain node belong to the second node device. Wherein, if the off-chain collaboration task is a subtask of the off-chain computing task, the task event for the off-chain collaboration task is generated by the off-chain computing contract when the task completion status meets the execution conditions of the off-chain collaboration task.

2. The method according to claim 1, wherein the task completion status is updated by the off-chain computing contract in response to the transaction corresponding to the off-chain computing task, wherein, The transactions corresponding to the off-chain computing tasks include task creation transactions corresponding to the off-chain computing tasks, or result return transactions initiated by any node device after completing any of the sub-tasks.

3. The method according to claim 1, wherein determining that the timestamp and the public key indicate that the requester is a second computing engine, includes: If the signature is verified by the public key of the second computing engine, and there is no valid historical request in the cache of the first computing engine that is in the same state as the data acquisition request, then the timestamp and the public key indicate that the requester is the second computing engine.

4. The method according to claim 3, further comprising: If the timestamp and the public key indicate that the requester is a second computing engine, the data retrieval request is recorded in the cache or the data retrieval request is set to a valid state in the cache. as well as, If the current time exceeds the time interval corresponding to the timestamp or if it is determined that the target data has been successfully returned to the second computing engine, delete the data retrieval request recorded in the cache or update the data retrieval request to an invalid state in the cache.

5. The method according to claim 1, wherein returning the target data to the second computing engine comprises: If the second computing engine has permission to access the target data, and / or the current time is within the time interval corresponding to the timestamp, the target data will be returned to the second computing engine.

6. The method according to claim 5, wherein the first computing engine maintains an authorization list, the authorization list being used to record the identity information of each party authorized to acquire the target data, and determining that the second computing engine has the authority to acquire the target data, includes: If the public key of the second computing engine is recorded in the authorization list or the public key is in a valid state, it is determined that the second computing engine has the right to obtain the target data.

7. The method according to any one of claims 4-6, wherein the timestamp is spaced apart from the start time of the time interval by a first duration and from the end time of the time interval by a second duration.

8. The method according to claim 1, further comprising: If the timestamp and the public key indicate that the requester is not the second computing engine, the target data will not be returned to the second computing engine.

9. The method according to claim 1, wherein returning the target data to the second computing engine comprises: The target data is returned to the second computing engine through the consensus link between the first blockchain node and the second blockchain node; or, The target data is returned to the second computing engine through a direct connection between the first and second computing engines.

10. The method according to claim 9, wherein the direct connection channel is established in the following manner: The system receives the address information of the second computing engine forwarded by the first node device, and establishes the direct connection channel with the second computing engine based on the address information. The address information is sent from the second node device to the first node device via the consensus link between the first and second blockchain nodes when the task event indicates that the first and second blockchain nodes are participants in the off-chain collaborative task.

11. The method according to claim 1, wherein the public key of the second computing engine includes the node public key of the second blockchain node.

12. A data processing method applied to a second computing engine, wherein a second blockchain node is deployed in a second node device where the second computing engine is located, and an off-chain computing contract is deployed on the blockchain network to which the second blockchain node belongs, the off-chain computing contract maintaining the task completion status of an off-chain computing task, the task completion status being used to describe the completion status of each subtask included in the off-chain computing task; the method comprising: When the task event generated by the off-chain computing contract indicates that the first blockchain node and the second blockchain node are participants in executing the off-chain collaborative task generated by the off-chain computing contract, a data acquisition request for the target data is initiated to the first computing engine. The data acquisition request includes a timestamp, the data identifier of the target data, the public key of the second computing engine, and a signature generated by the second computing engine based on its own private key for the timestamp, the data identifier, and the public key. The first computing engine and the first blockchain node belong to the first node device. When the off-chain collaborative task is a subtask of the off-chain computing task, the task event for the off-chain collaborative task is generated by the off-chain computing contract when the task completion status meets the execution conditions of the off-chain collaborative task. Receive the target data returned by the first computing engine when the timestamp and the public key indicate that the initiator of the data acquisition request is the second computing engine; The off-chain collaboration task is executed based on the target data.

13. The method according to claim 12, wherein the second node device further comprises a second scheduling framework, which obtains the off-chain collaborative task in the following manner: The off-chain collaborative task is received by the second scheduling framework in response to the listened-upon task event and distributed to the first computing engine.

14. The method according to claim 13, wherein the off-chain collaborative task is distributed to the second computing engine by the second scheduling framework if the computing type of the second computing engine matches the task type of the off-chain collaborative task.

15. The method according to claim 12, wherein performing the off-chain collaborative task comprises: The second computing engine itself executes the off-chain collaborative tasks; or, The second computing engine invokes the remote computing engine to execute the off-chain collaborative task.

16. The method of claim 12, further comprising: The execution result of the off-chain collaborative task is returned to the second computing node via the second node device; or, When the off-chain collaborative task is distributed to the second computing engine by the second scheduling framework corresponding to the second blockchain node, the execution result of the off-chain collaborative task is returned to the second computing node through the second scheduling framework.

17. A data processing apparatus applied to a first computing engine, wherein a first blockchain node is deployed in a first node device where the first computing engine is located, and an off-chain computing contract is deployed in the blockchain network to which the first blockchain node belongs, the off-chain computing contract maintaining the task completion status of an off-chain computing task, the task completion status describing the completion status of each sub-task included in the off-chain computing task; the apparatus comprises: A request receiving unit is used to receive a data acquisition request initiated by a requester for target data. The data acquisition request includes a timestamp, a data identifier of the target data, the requester's public key, and a signature generated by the requester based on its own private key for the timestamp, the data identifier, and the public key. A data return unit is used to return the target data to the second computing engine for executing the off-chain collaboration task generated by the off-chain computing contract, when the timestamp and the public key indicate that the requester is the second computing engine. The second computing engine and the second blockchain node belong to the second node device. Wherein, when the off-chain collaboration task is a subtask of the off-chain computing task, the task event for the off-chain collaboration task is generated by the off-chain computing contract when the task completion status meets the execution conditions of the off-chain collaboration task.

18. A data processing apparatus applied to a second computing engine, wherein a second blockchain node is deployed in a second node device where the second computing engine is located, and an off-chain computing contract is deployed on the blockchain network to which the second blockchain node belongs. The off-chain computing contract maintains the task completion status of an off-chain computing task, and the task completion status is used to describe the completion status of each sub-task included in the off-chain computing task; the apparatus comprises: The request initiating unit is used to initiate a data acquisition request for target data to the first computing engine when the task event generated by the off-chain computing contract indicates that the first blockchain node and the second blockchain node are participants in executing the off-chain collaborative task generated by the off-chain computing contract. The data acquisition request includes a timestamp, a data identifier of the target data, the public key of the second computing engine, and a signature generated by the second computing engine based on its own private key for the timestamp, the data identifier, and the public key. The first computing engine and the first blockchain node are first node devices. When the off-chain collaborative task is a subtask of the off-chain computing task, the task event for the off-chain collaborative task is generated by the off-chain computing contract when the task completion status meets the execution conditions of the off-chain collaborative task. A data receiving unit is configured to receive the target data returned by the first computing engine when the timestamp and the public key indicate that the initiator of the data acquisition request is the second computing engine; The task execution unit is used to execute the off-chain collaborative task based on the target data.

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

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

Images