CN114726537B - Data processing method and device - Google Patents
Data processing method and device Download PDFInfo
- Publication number
- CN114726537B CN114726537B CN202210343989.0A CN202210343989A CN114726537B CN 114726537 B CN114726537 B CN 114726537B CN 202210343989 A CN202210343989 A CN 202210343989A CN 114726537 B CN114726537 B CN 114726537B
- Authority
- CN
- China
- Prior art keywords
- computing engine
- task
- under
- token
- computing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 18
- 238000000034 method Methods 0.000 claims abstract description 90
- 230000004044 response Effects 0.000 claims abstract description 25
- 239000003999 initiator Substances 0.000 claims description 35
- 238000012545 processing Methods 0.000 claims description 25
- 238000012795 verification Methods 0.000 claims description 20
- 238000004364 calculation method Methods 0.000 claims description 14
- 238000013475 authorization Methods 0.000 claims description 13
- 238000003860 storage Methods 0.000 claims description 12
- 230000000977 initiatory effect Effects 0.000 claims description 11
- 230000008569 process Effects 0.000 description 27
- 238000004891 communication Methods 0.000 description 15
- 238000010586 diagram Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 12
- 230000005540 biological transmission Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 8
- 230000006872 improvement Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 230000003993 interaction Effects 0.000 description 7
- 238000012544 monitoring process Methods 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 230000009133 cooperative interaction Effects 0.000 description 5
- 238000009826 distribution Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 150000001875 compounds Chemical class 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 108010001267 Protein Subunits Proteins 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
Abstract
The embodiment of the specification provides a data processing method and device. The method is applied to a first computing engine deployed in first node equipment, and a blockchain network to which a first blockchain node deployed in the first node equipment belongs is deployed with a chain computing contract; comprising the following steps: determining the data identification of each participant of the under-chain cooperative task according to the task event generated by the under-chain computation contract and the target data required by executing the task; generating a token according to the random number, the data identification and the public key of the second computing engine and providing the token to the second computing engine under the condition that the task event indicates that the first blockchain node and the second blockchain node belong to the participants of the under-chain cooperative task; in response to a data acquisition request containing the token and its first signature, the target data is returned to the second computing engine for execution of the under-chain collaborative task if the token and its first signature indicate that the request was initiated by the second computing engine.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technology, and in particular, to a data processing method and apparatus.
Background
Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Nodes in the blockchain network verify and store data using a chained data structure and employ a distributed node consensus algorithm to generate and update the data. Intelligent contracts deployed in a blockchain may generate blockchain tasks that need to be performed under the chain. In the process that a plurality of block chain nodes participate in executing the task respectively, the related parties corresponding to the block chain link points respectively can need to conduct data interaction. For example, a manager of data corresponding to any one blockchain node may need to provide self-maintained data to requesters of data corresponding to other blockchain nodes in order for the latter to perform the above-described blockchain tasks using the data.
In the related art, a requester of data typically adds its own signature in an initiated data acquisition request so that a manager provides it with the required data if the signature is verified. Although the scheme realizes the authority control to a certain extent on the acquired data, the replay attack is still difficult to solve: the data acquisition request initiated by the requester may be intercepted by a third party and sent to the manager again, and since the replay request received again still contains the signature of the requester, the replay request can still pass the verification of the manager and get a normal response, so that the data maintained by the manager will be output to the third party, and a great potential safety hazard exists.
Disclosure of Invention
In view of this, one or more embodiments of the present description provide a data processing method and apparatus.
In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
according to a first aspect of one or more embodiments of the present disclosure, a data processing method is provided and 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 a blockchain network to which the first blockchain node belongs is deployed with a downlink computation contract; the method comprises the following steps:
determining each participant of the under-link collaboration task and a data identifier of target data required for executing the under-link collaboration task according to a task event for the under-link collaboration task, wherein the task event is generated by the under-link computation contract;
generating a token according to the random number, the data identifier and a public key of a second computing engine and providing the token to the second computing engine, wherein the second blockchain node and the second computing engine are deployed on second node equipment under the condition that the task event indicates that the first blockchain node and the second blockchain node belong to participants of the under-chain cooperative task;
In response to a data acquisition request containing the token and its first signature, returning the target data to a second computing engine for performing the under-chain collaborative task if the token and its first signature indicate that the data acquisition request was initiated by the second computing engine; wherein the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising: the first signature is generated by the second computing engine for the token using its own private key.
According to a second aspect of one or more embodiments of the present disclosure, another data processing method is provided and applied to a second computing engine, where a second blockchain node is deployed in a second node device where the second computing engine is located, and a blockchain network to which the second blockchain node belongs is deployed with an under-chain computing contract; the method comprises the following steps:
obtaining a token generated by a first computing engine, wherein the token is generated by the first computing engine according to a random number, a data identifier of target data required for executing the under-chain cooperation task and a public key of the second computing engine under the condition that a task event shows that a first blockchain node and a second blockchain node belong to a participant of the under-chain cooperation task, the task event is generated by the under-chain computing contract, and the first blockchain node and the first computing engine are deployed on first node equipment;
Generating a first signature on the token by using a private key of the first computing engine, initiating a data acquisition request containing the token and the first signature thereof to the first computing engine, and receiving target data returned by the first computing engine when the token and the first signature thereof indicate that the data acquisition request is initiated by a second computing engine;
and executing the under-chain cooperation task according to the target data.
According to a third aspect of one or more embodiments of the present disclosure, a data processing apparatus is provided, which is applied to a first computing engine, where a first blockchain node is disposed in a first node device where the first computing engine is located, and where an under-chain computing contract is disposed in a blockchain network to which the first blockchain node belongs; the device comprises:
a participant determining unit, configured to determine, according to a task event for an under-link collaboration task, a data identifier of each participant of the under-link collaboration task and target data required for executing the under-link collaboration task, where the task event is generated by the under-link computation contract;
the token generation unit is used for generating a token according to the random number, the data identifier and the public key of the second computing engine and providing the token to the second computing engine when the task event indicates that the first blockchain node and the second blockchain node belong to the participants of the under-chain cooperative task, and the second blockchain node and the second computing engine are deployed on second node equipment;
A data return unit for returning the target data to a second computing engine for executing the under-chain collaborative task in response to a data acquisition request including the token and its first signature, in the event that the token and its first signature indicate that the data acquisition request was initiated by the second computing engine; wherein the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising: the first signature is generated by the second computing engine for the token using its own private key.
According to a fourth aspect of one or more embodiments of the present disclosure, another data processing apparatus is provided, which is applied to a second computing engine, where a second blockchain node is disposed in a second node device where the second computing engine is located, and where an under-chain computing contract is disposed in a blockchain network to which the second blockchain node belongs; the device comprises:
the token acquisition unit is used for acquiring a token generated by the first computing engine, wherein the token is generated by the first computing engine according to a random number, a data identifier of target data required for executing the under-chain cooperation task and a public key of the second computing engine when a task event shows that a first blockchain node and a second blockchain node belong to a participant of the under-chain cooperation task, the task event is generated by the under-chain computing contract, and the first blockchain node and the first computing engine are deployed on first node equipment;
A data request unit, configured to generate a first signature on the token using a private key of the first computing engine, initiate a data acquisition request including the token and a first signature thereof to a first computing engine, and receive the target data returned by the first computing engine when the token and the first signature thereof indicate that the data acquisition request is initiated by a second computing engine;
and the task execution unit is used for executing the under-chain cooperative task according to the target data.
According to a fifth aspect of one or more embodiments of the present specification, there is provided an electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of the first or second aspect by executing the executable instructions.
According to a sixth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first or second aspect.
According to the technical scheme, when a task event generated by the under-chain computation contract shows that a first blockchain node and a second blockchain node belong to a participant of an under-chain cooperative task, a token (or token) is generated according to a random number, a data identifier of target data contained by the task event and a public key of the second computation engine, and is provided to the second computation engine; further, in response to a data acquisition request containing the token and its first signature, the target data is returned to the second computing engine for execution of the under-chain collaborative task if the token and its first signature indicate that the data acquisition request was initiated by the second computing engine.
The first computing engine generates the token using the random number and the identity information of the second computing engine, i.e., the token corresponds to the second computing engine. It will be appreciated that because the first signature included in the data acquisition request was generated by the initiator of the data acquisition request for the token, the token and its first signature indicate that the data acquisition request was initiated by the second computing engine, i.e., that the first signature was generated by the initiator of the request, and that the token corresponds to the second computing engine; in other words, the second computing engine is the initiator of the data acquirer, and the token carried in the request is the token generated by the first computing engine using the second computing engine. If the third party intercepts the token sent by the first computing engine to the second computing engine and generates a first signature by using the private key of the third party, the replay request containing the signature cannot pass verification; if the third party intercepts the data acquisition request sent by the second computing engine to the first computing engine and replays the request, the token carried by the request is inconsistent with the request initiator, and in the two cases, the token and the first signature thereof cannot be obtained to indicate that the data acquisition request is initiated by the second computing engine, so that the first computing engine can be prevented from responding to the replay request initiated by the third party to return target data to the first computing engine, and potential safety hazards possibly brought by replay attack initiated by the third party are eliminated.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a flow chart of a data processing method according to an exemplary embodiment.
FIG. 2 is a flowchart of another data processing method provided by an exemplary embodiment.
FIG. 3 is an interactive flow chart of a data processing method provided by an exemplary embodiment.
Fig. 4 is a schematic diagram of an apparatus according to an exemplary embodiment.
Fig. 5 is a block diagram of an apparatus for a data processing method according to an exemplary embodiment.
Fig. 6 is a block diagram of an apparatus of another data processing method provided by an exemplary embodiment.
Detailed Description
Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.
It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.
In the related art, a requester of data typically adds its own signature in an initiated data acquisition request so that a manager provides it with the required data if the signature is verified. Although the scheme realizes the authority control to a certain extent on the acquired data, the replay attack is still difficult to solve: the data acquisition request initiated by the requester may be intercepted by a third party and sent to the manager again, and since the replay request received again still contains the signature of the requester, the replay request can still pass the verification of the manager and be processed normally, so that the data maintained by the manager will be output to the third party, and a great potential safety hazard exists.
To solve the above-mentioned problems in the related art, the present specification proposes a data processing method in which a token is generated by a first computing engine (i.e., a manager of target data) using a public key of a second computing engine and provided to the second computing engine (i.e., a requester of target data) so that the second computing engine uses the token to prove that the second computing engine itself is indeed the true initiator of a data acquisition request. The scheme is described in detail below with reference to the accompanying drawings.
Referring to fig. 1, fig. 1 is a flowchart of a data processing method according to an exemplary embodiment. As shown in fig. 1, the method is applied to a first computing engine, a first blockchain node is deployed in first node equipment where the first computing engine is located, and a blockchain network to which the first blockchain node belongs is deployed with a downlink computing contract; the method comprises steps 102-106.
Step 102, determining each participant of the under-link collaboration task and a data identifier of target data required for executing the under-link collaboration task according to a task event for the under-link collaboration task, wherein the task event is generated by the under-link computation contract.
For a plurality of blockchain nodes included in a blockchain network, the present embodiments focus primarily on any two of the blockchain nodes, namely a first blockchain node and a second blockchain node. The second node device with the first blockchain node (i.e., the node device with the first blockchain node) is further provided with a first computing engine, and similarly, the second node device with the second blockchain node (i.e., the node device with the second blockchain node) is further provided with a second computing engine. The above-mentioned blockchain network has an under-chain computing contract deployed therein, and each blockchain node in the blockchain network may execute the contract to generate a task event for an under-chain collaboration task, for example, any blockchain node may invoke and execute the contract in the course of executing a blockchain transaction to generate the task event. Accordingly, the node device where any blockchain node is located may monitor the task event generated by the blockchain node, for example, the first node device may monitor the task event generated by the first blockchain node executing the above-mentioned under-chain computation contract, and the second node device may monitor the task event generated by the second blockchain node executing the above-mentioned under-chain computation contract.
In the embodiment of the present specification, the under-link computation contract is an on-link carrier for carrying the under-link computation task, and several subtasks included in the under-link computation task may be defined in the under-link computation contract, so as to describe a data flow direction in the under-link computation task and a computation collaboration process of each participant. Because the under-chain computing contracts are deployed on the blockchain network, the participants defining the under-chain computing tasks defined by the under-chain computing contracts do not exceed the scope of the blockchain nodes in the blockchain network. Obviously, a plurality of under-chain computing contracts can be deployed in the same blockchain network, and the number and the performance of the involved participant nodes of different under-chain computing contracts can be flexibly configured, so that the deployment of the under-chain computing tasks with different task types, task requirements and task scales can be realized by means of the same blockchain network.
To illustrate how an under-chain computing contract directs to implement its defined under-chain computing task, the logic for implementing the under-chain computing task will be briefly described below in terms of the course of operation of a typical under-chain computing contract.
A user may generate code for an under-chain computation contract through a visual compound reduction orchestration system and deploy the under-chain computation contract in a blockchain network, thereby defining a workflow of some type of under-chain computation task in the under-chain computation contract, which is embodied as a number of sub-tasks with execution dependency orders. Under the condition that the deployment of the under-chain computing contract is successful, a user with permission to call the under-chain computing contract can create and start the under-chain computing task by initiating a task creation transaction to the contract, a task instance of the under-chain computing task which belongs to the initiator user can be correspondingly created after the under-chain computing task creation transaction, and the task instance maintains the task completion state of the under-chain computing task and is embodied as the task completion state of each subtask under the under-chain computing task.
After the under-chain computing contract responds to the task creation transaction and generates a corresponding task instance, the execution of a first subtask corresponding to the instance is further triggered, and a task event for indicating a participant of the first subtask is generated on the under-chain computing contract. Each blockchain node in the blockchain network may monitor the task event and those node devices where blockchain nodes that determine themselves to be participants in the first subtask may further invoke the sub-chain resources matching the first subtask to execute the first subtask under the chain. After the execution is completed, the node device where the blockchain node serving as the participant is located further initiates a result return transaction carrying the execution result of the first subtask to the under-chain computing contract, so that the under-chain computing contract updates the task completion state of the corresponding task instance. For example, when the execution result of the first subtask is that the execution is successful, the under-chain computing contract may mark the task completion status of the first subtask in the corresponding task instance as completed, so as to trigger the execution of the next batch of subtasks according to the dependency sequence of each subtask included in the predefined under-chain computing task, and further generate an event including a participant node of the next batch of subtasks for monitoring of each block link point in the block chain network, and the subsequent process is similar to the process of processing the first subtask. Thus, a cycle of' the update task completion state of the under-chain computation contract → the generation of subtask events of the under-chain computation contract → the monitoring of subtask events by block chain link points and the execution of subtask events by the designated node device → the return of the result of the initiator task of the under-chain computation contract to the transaction → the update task completion state of the under-chain computation contract → is formed until the task completion states of all subtasks in the task instance of the under-chain computation contract are completed, and it can be determined that the under-chain computation task corresponding to the task instance is executed and completed.
It is not difficult to find that the under-chain computing is only used for executing the schedulable tasks such as creating task examples, receiving subtask results, scheduling and issuing subtasks in the execution process of the under-chain computing tasks, and actually does not really execute the actual tasks such as the computing, the data transferring and the data storing which are defined and required to be executed by the under-chain computing tasks, but the tasks which consume a large amount of resources are scheduled to be executed by the under-chain computing engines deployed in the node devices, so that the distributed computing based on the blockchain is realized through an event monitoring mechanism and a transaction return mechanism, the under-chain computing tasks are anchored by the under-chain computing contracts on the blockchain, and under-chain resources are fully utilized on the premise of ensuring that the whole process of task execution is trackable, and meanwhile, the trusted information interaction and collaborative computing are realized between different node devices by virtue of the blockchain. In addition, since the under-chain computing tasks are defined in a contract form and the design of the under-chain computing tasks is not subject to the toggle of the on-chain resources, this means that different actual demands can be met by designing different under-chain computing contracts, and the on-chain collaboration mode is extended by the under-chain resources.
In the embodiment of the present specification, the under-link computation contract maintains a task completion state corresponding to an under-link computation task, where the task completion state is used to describe a completion state of each subtask included in the under-link computation task; wherein in case an under-chain collaborative task belongs to a subtask of the under-chain computing task, the task event may be generated by the under-chain computing contract in case the task completion status satisfies an execution condition of the under-chain collaborative task, and a node device may monitor the task event through an event monitoring mechanism. In the embodiment of the present disclosure, the task completion status of the computing task under the chain may be maintained in a corresponding task instance of the computing contract under the chain, and specifically, the completion status of each subtask may be maintained in the task instance. Since the execution dependency sequence of each subtask included in the under-chain computing task has been predefined, which means that the execution condition of each subtask is also determined, the under-chain computing contract can further determine the under-chain cooperative task to be executed next according to the completion status of each subtask, thereby initiating a task event for the under-chain cooperative task.
Further, the node device executing the under-chain cooperative task may initiate, by the self-deployed blockchain node, a result return transaction including an execution result of the under-chain cooperative task to the under-chain computation contract under the condition that the task is completed, so as to update a task completion state of the under-chain computation task maintained by the under-chain computation contract. As described above, in the case where the node device executes the under-chain cooperative task by calling the resource and finishes execution, the task completion status of the under-chain computation task maintained by the under-chain computation contract may be updated by initiating the result return transaction, so that the under-chain computation contract may further determine the next sub-task that should be executed next according to the execution dependency order of each sub-task in the under-chain computation task, and generate a task event for the next sub-task. In the embodiment of the specification, the task event generated by the monitoring of the under-chain computation contract and the initiation of the result return transaction to the under-chain computation contract can be completed by a scheduling framework deployed on the first node device.
As described above, the task completion status is updated by the under-link computation contract in response to the transaction corresponding to the under-link computation task, where the transaction corresponding to the under-link computation task may include a task creation transaction corresponding to the under-link computation task, or a return transaction of a result initiated by any node device when executing any of the subtasks is completed.
Therefore, the under-link collaboration task in the embodiment of the present disclosure may be a special subtask of a plurality of subtasks included in the under-link computation task, and is characterized in that the under-link collaboration task requires a plurality of participants to cooperate under the link, and execution of the task is completed through cooperative interaction. Of course, all subtasks included in the under-chain computing task may be the under-chain cooperative task, and in this case, the embodiment of the present disclosure focuses only on the execution process of any one of the under-chain cooperative tasks; alternatively, the under-link computing task may include only one under-link collaboration task, which is not limited by the embodiments of the present disclosure.
In the embodiment of the present specification, the under-link computation contract maintains task completion states corresponding to one or more under-link collaboration tasks respectively. Typically, an under-link computation contract only defines one type of under-link collaboration task, but multiple task instances corresponding to the under-link collaboration task can be created, where each task instance records a task completion state corresponding to the task instance. Thus, multiple task instances maintained on the under-chain computing contract may be triggered and created by different users by respectively launching a task creation contract to the under-chain computing contract, or may be triggered and created by the same user by launching the task creation contract multiple times, but all have the same execution logic, i.e., the task types of the tasks maintained by the under-chain computing contract are the same.
The first node device may further deploy a first scheduling frame corresponding to the first blockchain node, and the second node device may further deploy a second scheduling frame corresponding to the second blockchain node. As mentioned above, the specific process of the first node device and the second node device monitoring the task event may be implemented by the first scheduling frame and the second scheduling frame, respectively, that is, the first scheduling frame and the second scheduling frame may monitor the task event respectively. On this basis, the first scheduling framework may distribute the under-chain collaboration task to the first computing engine for execution according to the monitored task event. Similarly, the second scheduling framework may distribute the under-chain collaborative tasks to a second compute engine for execution based on the monitored task events. By the method, the distribution process of the under-chain cooperative tasks is completed by the scheduling framework without participation of node equipment or block link points, so that the independence of the task distribution process is realized, and the efficient distribution under a multi-task scene is convenient to realize.
The scheduling framework can realize the task distribution according to the task type of the under-chain cooperative task. For example, the second scheduling framework may first determine a task type of the under-chain collaboration task and a computation type of the second compute engine, and issue the under-chain collaboration task to the second compute engine if the computation type matches the task type. In particular, in the case where a plurality of computing engines are deployed in the second node device, the second scheduling framework may sequentially determine a computing type of each of the second computing engines, then determine at least one second computing engine whose computing type matches the task type from each of the second computing engines, further select a second target computing engine among the second computing engines, and then issue the under-link collaboration task to the second target computing engine for execution. Similarly, the first scheduling framework may first determine a task type of the under-chain collaboration task and a computation type of the first computing engine, and issue the under-chain collaboration task to the first computing engine if the computation type matches the task type. In particular, in the case where a plurality of computing engines are deployed in the first node device, the first scheduling framework may sequentially determine a computing type of each of the first computing engines, then determine at least one first computing engine whose computing type matches the task type from each of the second computing engines, further select a first target computing engine among the first computing engines, and then issue the under-link collaboration task to the first target computing engine for execution. The above calculation type and task type may be a forwarding type, an MFT (Managed File Transfer, large file transfer) type, a privacy calculation type, a data query type, and the like, which is not limited by the embodiment of the present specification. By the method, the scheduling framework can distribute the under-chain cooperative tasks to the corresponding type of computing engines, and smooth and efficient execution of the under-chain cooperative tasks is facilitated.
In the event of a task event being monitored, the first node device may forward the task event to the first computing engine, such that the first computing engine may determine, in a number of ways, the respective participants of the under-chain collaborative task and the data identification of the target data required to perform the under-chain collaborative task. As described above, the task event generated by the above-mentioned under-link computation contract may be used to indicate each participant of the under-link collaboration task and target data required for executing the under-link collaboration task, for example, identity information such as public keys of each participant and the data identifier of the target data may be recorded in the event, so that the first computation engine may obtain the identity information of each participant and the data identifier of the target data from the task event. In this way, the under-chain computing contract may inform each compute engine of the information that each compute engine needs to learn to perform the under-chain collaboration task by way of task events. Or in the process of deploying the above-mentioned under-chain computing contracts, the deployment party or the visual compound contract arrangement system of the contracts can collect the identity information of the computing engines corresponding to all the participants in advance, and generate codes of the under-chain computing contracts according to the identity information, and at this time, the task event generated by the contracts can not contain the identity information of all the participants and the data identification of the target data. In this case, the first calculation engine may determine the under-chain calculation contract according to the task event, and read, through the first block link point, the identity information of each participant and the data identifier of the target data recorded in the under-chain calculation contract. As described above, although each blockchain node is a participant in the under-chain cooperative task, the execution subject of the task is actually a computing engine corresponding to each participant, so the task event may include, in addition to the data identifier of the target data, identity information of each computing engine, such as identity information of a manager (e.g. the first computing engine) that maintains the target data, identity information of a requester (e.g. the second computing engine) that needs to acquire the target data, and so on. Wherein, the identity information of any party can be the public key of the party; of course, in the case where any blockchain node corresponds to only one compute engine, the compute engine may use the public key of that blockchain node as its own public key to simplify the number of public keys that each interested party needs to maintain.
Step 104, generating a token according to the random number, the data identifier and the public key of the second computing engine, and providing the token to the second computing engine, wherein the second blockchain node and the second computing engine are deployed on the second node device, when the task event indicates that the first blockchain node and the second blockchain node belong to the participants of the under-chain cooperative task.
As previously described, an under-chain collaboration task requires multiple blockchain nodes to interoperate, i.e., the task has multiple participants, and the task event described above is used to indicate the identity of each participant of the under-chain collaboration task. For example, the task event may include descriptive information of each participant of the under-chain collaboration task, such as identification information of a node public key of each participant, for informing the block link point of which participants need to participate in performing the task. The task event contains descriptive information of each participant of the under-chain collaboration task, which means that the under-chain collaboration task specifies identity information of each blockchain node that it needs to participate in. In addition, task identifiers of the under-chain computing tasks and the under-chain cooperative tasks can be recorded in the task event, so that different tasks and sub-tasks can be distinguished, which is mainly convenient for the subsequent node equipment to correctly identify the result of the under-chain cooperative tasks in the under-chain computing tasks when the execution of the under-chain cooperative tasks is finished and the return result is returned to the transaction, so that the under-chain computing contracts can correctly update the completion state of the under-chain cooperative tasks in the task instances corresponding to the under-chain computing tasks through the result return transaction, and the situation that one task comprises a plurality of sub-tasks or the task instances of a plurality of under-chain computing tasks are simultaneously created in the same under-chain computing annual contract can be dealt with.
Under the condition that the first node device monitors the task event, each participant of the under-link cooperative task can be determined according to the task event, for example, if the description information contains identification information of a certain blockchain node, the first node device can determine that the blockchain node is the participant of the under-link cooperative task. Taking the first blockchain node as an example, if the description information contains identification information of the first blockchain node, the first node device can determine that the first blockchain node belongs to a participant of an under-chain cooperation task, and then the first node device needs to start to process the under-chain cooperation task; and if the description information does not include the identification information of the first blockchain node, the first node device may determine that the first blockchain node does not belong to a participant of the under-chain collaboration task, and then the first node device will not process the under-chain collaboration task. In fact, in the task event, task information such as a source of target data (i.e., a computing engine for storing target data required for executing the under-link collaboration task) that needs to be transferred between each participant in the task type of the under-link collaboration task may also be recorded, where the task information is used to inform each node device of the task type of the under-link collaboration task and its implementation manner, so as to instruct the node device to execute the task according to the expectation of the under-link collaboration task after determining the callable resource. Based on the description information, whether the first blockchain node and the second blockchain node are participants of the under-chain cooperative task or not can be determined; based on the task information, it may be further determined whether the first blockchain node and the second blockchain node are a manager and a requester of the target data, respectively; in other words, the task event may be used to indicate whether the first blockchain node and the second blockchain node are participants in the determination of the under-chain collaborative task and are the manager and the requester of the target data, respectively.
It will be appreciated that the token generated by the first computing engine is used to obtain target data from the first computing engine, i.e. the token is used by a requester of target data to be included in an initiated data acquisition request when requesting to obtain target data to prove the identity of the requester to the first computing engine. It is apparent that the first computing engine is only able to return target data to a requestor of the target data (e.g., a second computing engine) if the first computing engine is indeed a manager of the target data, nor is the first computing engine necessary to generate the token. Thus, the first compute engine may trigger generation of the token if the task event indicates that the first blockchain node and the second blockchain node are participants of an under-chain collaborative task and are the manager and the requester of the target data, respectively.
In an embodiment, to ensure that the target data can only be acquired by the related party having the corresponding authority, the first computing engine may first determine whether the second computing engine has the authority to acquire the target data, and generate the token according to the random number, the data identifier and the public key of the second computing engine if it is determined that the second computing engine has the authority. Wherein the first computing engine may maintain an authorization list for the target data, the list being used to record identity information of each acquirer that is allowed to acquire the target data. For example, the first computing engine may determine identity information for each legitimate acquirer that is allowed to acquire the target data based on the task events described above or other in-chain manner. Further, the first computing engine may record the determined identity information in the authorization list, and may delete the corresponding identity information in the list if it is determined that any of the acquirers no longer has the authority. Alternatively, the first computing engine may record the determined identity information in the authorization list and set it to a right state, and update the corresponding identity information in the list to an unauthorized state if it is determined that any of the acquirers no longer has the right.
Based on the authorization list, the first computing engine can query the identity information or the authorization state of the second computing engine in the list, and determine that the second computing engine has the authority to acquire the target data under the condition that the identity information of the second computing engine exists in the list or the identity information is in a right state. In this way, only if the second computing engine is determined to have the right to acquire the target data, the first computing engine generates the token so that the second computing engine can acquire the target data by using the token, thereby controlling the right of the acquirer of the target data and the output process of the target data, and improving the security of the target data to a certain extent.
The first computing engine may generate the token under different trigger conditions, depending on the timing of the generation of the token. As an example embodiment, the first computing engine may proactively generate tokens for the second computing engine. For example, in the case where a data identification of the target data and a public key of a second computing engine may be included in the task event, a first computing engine may obtain the data identification and the public key of the second computing engine from the task event in response to the task event, and generate a token from a random number and the obtained data identification and the public key. The task event may be provided to the first computing engine by the first node device, such as by a first scheduling framework deployed in the first node device, and the task event may be issued to the first computing engine if the task event is monitored. For example, the first scheduling framework may issue the task event to each computing engine deployed in the first node device, so that the first computing engine may obtain, when determining itself as a manager of the target data, the data identifier and the public key of the second computing engine from the task event, and generate a token according to the random number and the obtained data identifier and the public key. For another example, the first scheduling framework may also determine a manager of the target data according to the monitored task event, and send the task event to the first computing engine when determining that the first computing engine is the manager, so as to avoid that other computing engines unrelated to the under-chain cooperative task acquire the task event, and avoid leakage of relevant information of the task to a certain extent; accordingly, the first computing engine may obtain the data identifier and the public key of the second computing engine from the task event, and generate a token according to the random number and the obtained data identifier and the public key. By the method, the first computing engine can actively generate the token for the corresponding data acquisition party (namely the second computing engine) under the condition that the first computing engine is the management party of the target data, so that the second computing engine can acquire the target data by using the token, the waiting time of the second computing engine can be reduced, and the acquisition efficiency of the second computing engine to the target data can be improved.
In another embodiment, the first computing engine may also generate the token in response to a received token acquisition request. For example, a first computing engine may receive a token acquisition request containing a data identification of target data, a public key of an initiator of the request, and a second signature generated by the initiator using its own private key for the data identification and the public key. At this point, the first compute engine may verify the second signature from the public key of the second compute engine recorded in the task event. If the verification is passed, the token acquisition request is indicated to be initiated by the second computing engine, and the token can be generated according to the random number, the data identification and the public key of the initiator (namely the second computing engine). If the verification is not passed, the request initiator is not the second computing engine, and considering that the request contains the public key for indicating the identity of the second computing engine, it can be determined that the actual initiator of the request is inconsistent with the initiator declared by the content in the request, that is, the request is likely to be a replayed false request, so that the first computing engine can refuse to generate a corresponding token in response to the request, so as to avoid the situation that the third party acquires the target data because of normally responding to the false request, and ensure the security of the target data. It can be seen that by verifying the second signature using the public key of the second calculation engine, the replayed token acquisition request can be identified, thereby avoiding the generation of tokens in response to such requests.
In the case where the token generation condition described in the foregoing embodiment is satisfied, the first computing engine may generate the token from the random number, the data identification of the target data, and the public key of the second computing engine. For example, the first computing engine may use, as the token, a data set formed by a random number, the data identifier, and the public key, where the data set may be a simple concatenation or a combination of the foregoing data, and the embodiment of the present disclosure is not limited to this. For another example, the first computing engine may also compute a digest of the data set and use the digest as the token.
It should be noted that the first calculation engine may generate the random number by using a random number generation algorithm or a pseudo random number generation algorithm, for example, an XorShift algorithm, a linear congruence method (LCG, linear congruential generator), a mosaic rotation algorithm (mersen twist), or the like may be used. It will be appreciated that the token is targeted to the computing engine because it is generated using the public key of the second computing engine; further, because the tokens are generated by using random numbers, each token generated by the first calculation engine is introduced with random variables, and therefore target data request errors possibly caused by repeated tokens can be further avoided: in scheme application, in response to two token acquisition requests which are normally initiated by the same computing engine aiming at the same target data, the probability of generating the same random number by using a random number generation algorithm is almost zero, so that the probability of generating two same tokens by the first computing engine is almost zero, and the scheme has strong practicability.
The first computing engine may record the generated token in its own cache. For example, the first computing engine may maintain a list of tokens that are used to record tokens generated by the first computing engine that are in a valid state. In the case of a data set of random numbers, data identifications and public keys as any token, the first calculation engine may record the token directly in the list; in the case of a digest of the data set as any token, the first calculation engine may record the random number, data identification and public key that generated the token, in addition to recording the token in the list. In other words, the corresponding relation among the token and the corresponding random number, the data identifier and the public key is recorded in the cache of the first computing engine.
Normally, the second computing engine needs to acquire the target data only once to execute the under-chain cooperative task, and even if the target data needs to be acquired multiple times, the target data should be acquired again if the previous acquisition fails or the token acquisition request processing is overtime. Thus, only one token need be used by the second compute engine for a single fetch of target data, i.e., the first compute engine need only generate one token for the same token fetch request. However, since the token acquisition request initiated by the second computing engine may be intercepted and replayed by a third party (of course, the second computing engine may also replay), the first computing engine may receive the token acquisition request containing the same content, and for this purpose, the first computing engine may deduplicate each received token acquisition request according to the history token recorded in the token list. For example, in response to a received token acquisition request containing a data identification of the target data and a public key of a second computing engine, a first computing engine may first query the token list for a history token generated using any random number, the data identification, and the public key of the second computing engine, before generating a token using the data identification and the public key of the second computing engine: if such a history token exists in the token list, it may be determined that the token acquisition request has been responded (i.e. a corresponding token has been generated from the information carried by the request, i.e. the history token is queried), so it may be determined that the token acquisition request is a replay attack, at which point processing of the request may be terminated, i.e. generation of a corresponding token from the data identifier contained in the request and the public key of the second computing engine is avoided. If the history token generated by using any random number, the data identifier and the public key of the second computing engine does not exist in the token list, the token acquisition request can be determined to be a request normally initiated by the second computing engine, so that the request can be normally processed, namely, a corresponding token is generated according to the random number, the data identifier contained in the request and the public key of the second computing engine. In this way, replay attacks initiated by the second computing engine or a third party against the token acquisition request can be effectively identified to avoid generating invalid tokens.
Further, after the normal processing of the token acquisition request to generate a token is completed, in one aspect, the first computing engine may provide the token to the second computing engine; alternatively, the first computing engine may record the token in the cache and set it to a valid state, e.g., may record the token in the token list or set the generated token in the token list to a valid state.
Step 106, in response to a data acquisition request containing the token and its first signature, returning the target data to a second computing engine for executing the under-chain collaboration task if the token and its first signature indicate that the data acquisition request was initiated by the second computing engine; wherein the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising: the first signature is generated by the second computing engine for the token using its own private key.
In the case of obtaining the token provided by the first computing engine, the second computing engine may generate a first signature for the token using its own private key and initiate a data obtaining request containing the token and the first signature to the first computing engine to request the first computing engine to obtain the target data. In response to the data acquisition request, the first computing engine may determine a (real) initiator of the data acquisition request from the token and the first signature, and in turn return the target data to the second computing engine for execution of the under-chain collaborative task if the token and its first signature indicate that the data acquisition request was initiated by the second computing engine, i.e., the second computing engine is determined to be the initiator of the request.
According to the technical scheme, when a task event generated by the under-chain computation contract shows that a first blockchain node and a second blockchain node belong to a participant of an under-chain cooperative task, a token (or token) is generated according to a random number, a data identifier of target data contained by the task event and a public key of the second computation engine, and is provided to the second computation engine; further, in response to a data acquisition request containing the token and its first signature, the target data is returned to the second computing engine for execution of the under-chain collaborative task if the token and its first signature indicate that the data acquisition request was initiated by the second computing engine.
The first computing engine generates the token using the random number and the identity information of the second computing engine, i.e., the token corresponds to the second computing engine. It will be appreciated that because the first signature included in the data acquisition request was generated by the initiator of the data acquisition request for the token, the token and its first signature indicate that the data acquisition request was initiated by the second computing engine, i.e., that the first signature was generated by the initiator of the request, and that the token corresponds to the second computing engine; in other words, the second computing engine is the initiator of the data acquirer, and the token carried in the request is the token generated by the first computing engine using the second computing engine. If the third party intercepts the token sent by the first computing engine to the second computing engine and generates a first signature by using the private key of the third party, the replay request containing the signature cannot pass verification; if the third party intercepts the data acquisition request sent by the second computing engine to the first computing engine and replays the request, the token carried by the request is inconsistent with the request initiator, and in the two cases, the token and the first signature thereof cannot be obtained to indicate that the data acquisition request is initiated by the second computing engine, so that the first computing engine can be prevented from responding to the replay request initiated by the third party to return target data to the first computing engine, and potential safety hazards possibly brought by replay attack initiated by the third party are eliminated.
In the case of receiving a data acquisition request containing the token and its first signature, the first computing engine may verify the first signature according to the public key of the second computing engine, and query all the tokens recorded in the cache for whether the token in a valid state exists, so that in the case that the first signature is verified according to the public key of the second computing engine and the token in a valid state exists in the cache of the first computing engine, it may be determined that the real initiator of the data acquisition request is indeed the second computing engine corresponding to the token generated by itself. It will be appreciated that if the verification mechanism adopted by the first computing engine for the second signature fails due to an unexpected situation, or if the third party intercepts the token generated by the first computing engine according to the public key of the second computing engine and provided to the second computing engine, the third party needs to generate the first signature using its own private key and include the first signature in the data acquisition request, and send the first signature to the first computing engine, i.e. falsified data acquisition request. Obviously, because the private keys of the third party and the second computing engine are not the same, the first signature cannot pass the verification of the public key of the second computing engine, so that the verification of the first signature can identify the fake request of the third party for the data acquisition request, and the request is prevented from being processed by the first computing engine. In addition, if the data acquisition request initiated by the second computing engine to the first computing engine is replayed by the second computing engine or intercepted and replayed by a third party, the first computing engine may identify the replay request based on the token recorded in the cache, since the interval time between the replay request and the data acquisition request is typically relatively short. In fact, in order to achieve a better recognition effect on the replay request of the data acquisition request, the token recorded in the above-mentioned cache may also be deleted after determining that the data acquisition request is initiated by the second computing engine or that the target data is successfully returned to the second computing engine between the segments, so as to achieve a better recognition and hit effect on the replay request.
In an embodiment, where a generated token is recorded in the token list, the first computing engine may delete the token recorded in the token list upon determining that the data acquisition request was initiated by the second computing engine or that the target data was successfully returned to the second computing engine. Alternatively, in the case where the generated token is recorded in the token list and set to the valid state, the first computing engine may update the token recorded in the token list to the invalid state upon determining that the data acquisition request is initiated by the second computing engine or that the target data is successfully returned to the second computing engine. In this way, any token generated by the first computing engine may be recorded in the token list, and in the case that the token is used up (it is determined that the data acquisition request is initiated by the second computing engine or it is determined that the target data is successfully returned to the second computing engine), the token is deleted from the token list or updated to an invalid state, so that a validity period is set for the token through the caching mechanism, and one-time use of the token is achieved.
In the event that it is determined by the above embodiments that the data acquisition request did originate for the second computing engine, the first computing engine may return the target data to the second computing engine for the latter to perform the chain of collaborative tasks using the data.
As can be seen from the foregoing embodiments, to perform the under-chain collaborative task, multiple interactions are required between the first computing engine and the second computing engine, for example, the second computing engine initiates a token acquisition request to the second computing engine and receives the token returned by the first computing engine, and the second computing engine initiates a data acquisition request to the second computing engine and receives the target data returned by the first computing engine. The first computing engine and the second computing engine can realize the interaction through a common link between the first blockchain node and the second blockchain node, taking the second computing engine for initiating a data acquisition request to the second computing engine and receiving the target data returned by the first computing engine as an example, the second computing engine can submit the data acquisition request to the second node equipment, and the second node equipment sends the request to the first node equipment through the common link between the first blockchain node and the second blockchain node, so that the first node equipment can forward the request to the first computing engine; accordingly, the first computing engine may submit the target data to the first node device and return the request to the second node device by the first node device over the consensus link, so that the second node device may forward the request to the second computing engine. The common link is a path used for transaction common or on-link data transmission between the first block chain node and the second block chain node, and the common link can be multiplexed in the mode, so that the utilization rate of the common link is improved. In addition, a first P2P component corresponding to the first block link point may be deployed in the first node device, a second P2P component corresponding to the second block chain node may be deployed in the second node device, and a common link between the first block chain node and the second block chain node may be a common link between the first P2P component and the second P2P component, which is not described herein.
Furthermore, in order to avoid transmission failure that may occur when the target data is transmitted through the consensus link or to interfere with the on-link processes such as the original transaction consensus of the consensus link, a direct connection channel may be established between the first computing engine and the second computing engine through the consensus link, and the interaction process between the first computing engine and the second computing engine in the embodiment of the present disclosure is completed based on the direct connection channel. For example, the first node device may send, over the consensus link, first address information of a first compute engine to a second node device where a second blockchain node is located, if the task event that is monitored indicates that the first blockchain node and the second blockchain node belong to participants of the under-chain collaborative task; accordingly, a second compute engine deployed on the second node device may establish a direct channel with the first compute engine according to the first address information. Similarly, the direct connection channel may also send, by the second node device, second address information of the second computing engine to the first node device where the first blockchain node is located through the consensus link when the task event monitored by the second node device indicates that the first blockchain node and the second blockchain node belong to the participants of the under-chain cooperative task; accordingly, a first computing engine deployed on the first node device may establish a direct channel with a second computing engine according to the second address information.
Any one of the address information can be network address information such as an IP address, a port number and the like of a corresponding computing engine, so that the network address of any computing engine can be accurately informed to other computing engines, and the establishment of a direct communication channel can be conveniently established subsequently; the system can also comprise identity information such as agent addresses, engine identifications and the like, and is used for accurately informing other computing engines of the identity of any computing engine, so that the other computing engines can orderly manage the established direct communication channels and the computing engines connected with the direct communication channels.
It will be appreciated that if the second computing engine establishes a direct connection with the first computing engine based on the address information, and the first computing engine also establishes a direct connection with the second computing engine based on the address information, the two direct connections after the establishment should be identical—the two direct connections differ only by the initiator of the establishment procedure. Therefore, to simplify the connection between the compute engines to facilitate maintenance and management of the direct channels, it is not necessary to establish the two direct channels between the second compute engine and the second compute engine simultaneously. To this end, the second node device may send second address information of the second computing engine to the first node device over the consensus link in case the task event indicates that the first and second blockchain nodes belong to participants of the under-chain collaborative task. And when the second computing engine does not establish the direct connection channel (namely, the direct connection channel established by the second computing engine and the first computing engine according to the first address information), if a channel establishment request initiated by the first computing engine according to the second address information is received, the direct connection channel can be established by returning a channel establishment response to the first computing engine. Of course, under the condition that the direct communication channel is successfully established, the first computing engine and the second computing engine can refuse to establish the direct communication channel again between the first computing engine and the second computing engine, so that repeated establishment of the direct communication channel is avoided, and the network structure of the downlink interaction network between the computing engines is simplified as much as possible on the basis of meeting the cooperative interaction requirement.
After the establishment of the direct communication channel is completed, the first computing engine and the second computing engine can realize cooperative interaction based on the channel when executing the under-link cooperative task. For example, a first computing engine may receive the data acquisition request initiated by a second computing engine through the direct communication channel; and/or the first computing engine can return the target data to the first computing engine through the direct-connection channel. By the method, the first computing engine and the second computing engine can realize cooperative interaction through the direct communication channel established between the first computing engine and the second computing engine, such as initiating a request or transmitting target data, and the like, only address information with smaller data quantity is transmitted by the common link, so that interference to the original on-link process based on the common link is avoided to a certain extent, and the direct communication channel is only used for data transmission between the second computing engine and the second computing engine, so that the possibility of error of target data transmission is reduced.
In the embodiment shown in fig. 1, the process of transmitting the target data in the present specification is actually described from the perspective of the first computing engine, and the technical solution of the present specification is described below from the perspective of the second computing engine with reference to fig. 2. It will be readily appreciated that the embodiment shown in fig. 2 does not differ from the embodiment shown in fig. 1 in nature, and that the foregoing description of the embodiment shown in fig. 1 applies to the embodiment shown in fig. 2.
Referring to fig. 2, fig. 2 is a flowchart of another data processing method according to an exemplary embodiment. As shown in fig. 2, the method is applied to a second computing engine, a second blockchain node is deployed in a second node device where the second computing engine is located, and a blockchain network to which the second blockchain node belongs is deployed with a downlink computing contract; the method includes steps 202-206.
Step 202, obtaining a token generated by a first computing engine, wherein the token is generated by the first computing engine according to a random number, a data identifier of target data required for executing the under-chain cooperation task and a public key of the second computing engine when a task event shows that a first blockchain node and a second blockchain node belong to a participant of the under-chain cooperation task, the task event is generated by the under-chain computing contract, and the first blockchain node and the first computing engine are deployed on first node equipment.
Step 204, generating a first signature on the token by using a private key of the first computing engine, and initiating a data acquisition request containing the token and the first signature thereof to the first computing engine, and receiving the target data returned by the first computing engine when the token and the first signature thereof indicate that the data acquisition request is initiated by the second computing engine.
And 206, executing the link-down cooperative task according to the target data.
As previously described, the second computing engine may initiate a token acquisition request to the first computing engine, the request containing a data identification of the target data, a public key of the second computing engine, and a second signature generated by the second computing engine on the data identification and the public key using its own private key; the token generated and returned by the first computing engine upon verification of the second signature based on the public key of the second computing engine is received, the token and its first signature being for inclusion in the data acquisition request.
As previously described, a second scheduling framework may also be deployed in the second node device such that the second computing engine may receive the under-chain collaborative task that the second scheduling framework distributes to the first computing engine in response to the monitored task event. Wherein the under-chain collaborative task may be distributed to the second compute engine by the second schedule framework if a compute type of the second compute engine matches a task type of the under-chain collaborative task.
In one embodiment, the second compute engine may perform the under-chain collaboration task itself; alternatively, where the second computing engine allows for invoking other remote computing engines (e.g., the second computing engine is a proxy computing engine deployed in the second node device), the second computing engine may invoke the remote computing engine to perform the chain of collaborative tasks. Similarly, the first computing engine may also execute the task by itself or by invoking a corresponding remote computing engine to execute the task under chain collaboration, which is not described in detail.
The second computing engine executing the under-chain collaborative task may obtain a corresponding execution result, after which the second computing engine may return the execution result to the second blockchain node. For example, the second computing engine may return the execution result of the under-chain cooperative task to the second scheduling framework, and the second scheduling framework uploads the execution result to the second blockchain node, e.g., may return the execution result to a task instance for the under-chain cooperative task generated in the second blockchain node, thereby completing a complete processing procedure for the under-chain cooperative task. In addition, in the case that the under-chain cooperative task is any sub-task of the under-chain computing task, the second blockchain node may update the task completion status of the under-chain computing task according to the execution result, for example, update the completion status of the sub-task, which is the under-chain cooperative task, to be completed, so as to trigger the under-chain computing task to advance the corresponding workflow, for example, trigger the execution of the next sub-task, and so on.
The details of the embodiments corresponding to the second computing engine may be referred to the description of the embodiments described in the foregoing first computing engine, which is not repeated herein.
By the scheme, the first computing engine generates the token by using the random number and the identity information of the second computing engine, and the token corresponds to the second computing engine. It will be appreciated that because the first signature included in the data acquisition request was generated by the initiator of the data acquisition request for the token, the token and its first signature indicate that the data acquisition request was initiated by the second computing engine, i.e., that the first signature was generated by the initiator of the request, and that the token corresponds to the second computing engine; in other words, the second computing engine is the initiator of the data acquirer, and the token carried in the request is the token generated by the first computing engine using the second computing engine. If the third party intercepts the token sent by the first computing engine to the second computing engine and generates a first signature by using the private key of the third party, the replay request containing the signature cannot pass verification; if the third party intercepts the data acquisition request sent by the second computing engine to the first computing engine and replays the request, the token carried by the request is inconsistent with the request initiator, and in the two cases, the token and the first signature thereof cannot be obtained to indicate that the data acquisition request is initiated by the second computing engine, so that the first computing engine can be prevented from responding to the replay request initiated by the third party to return target data to the first computing engine, and potential safety hazards possibly brought by replay attack initiated by the third party are eliminated.
Referring to fig. 3, fig. 3 is an interactive flowchart of a data processing method according to an exemplary embodiment. As shown in fig. 3, the method includes steps 301a-313.
In step 301a, the second computing engine obtains a task event or an under-link collaboration task that is monitored by the second node device.
In step 301b, the first computing engine obtains a task event or an under-link collaboration task that is monitored by the first node device.
In invoking and executing an under-chain computation contract by a blockchain node in a blockchain network, the contract may generate a task event for an under-chain collaborative task, and node devices where each blockchain node in the compute engine is located may each monitor the task event. The first node device may send the task event or the under-link collaboration task to the first computing engine if the task event indicates that the first block link point belongs to a participant of the under-link collaboration task; similarly, the second node device may send the task event or the under-chain collaboration task to the second compute engine if the task event indicates that the second blockchain node belongs to a participant of the under-chain collaboration task. The monitoring process for the task event can be completed by a scheduling framework deployed in each node device.
The task event or the under-link collaboration task can be used for designating target data required for executing the under-link collaboration task and a manager and a requester corresponding to the target data besides the identity of each participant of the under-link collaboration task. The following describes a process in which the second computing engine requests to acquire target data from the first computing engine and execute an under-chain collaboration task, taking as an example a manager of the target data of the first computing engine and a requester of the target data of the second computing engine.
In step 302, the second compute engine generates a second signature using the data identification of the target data by the private key of itself and the public key of the second compute engine.
In step 303, the second computing engine initiates a token acquisition request containing the data identification, the public key, and the second signature to the first computing engine.
In the event that it is determined from the task event that the second computing engine itself needs to obtain the target data from the first computing engine, the second computing engine may generate a second signature using the data identification of the target data by the private key of the second computing engine itself and the public key of the second computing engine. The identification of the target data can be obtained from the task event; the public key of the second computing engine may be obtained locally (the local public key of the second computing engine is maintained locally), or may be obtained from the task event, which is not limited by the embodiment of the present disclosure.
Further, in the case of generating the second signature described above, the second computing engine may initiate a token acquisition request containing the data identification, the public key, and the second signature to the first computing engine.
At step 304, the first computing engine verifies the second signature and the second computing engine's acquisition rights for the target data using the second computing engine's public key contained in the task event.
The first compute engine that receives the token acquisition request needs to determine if the request is valid. In one aspect, the first compute engine may verify the second signature contained in the request using a public key of a second compute engine contained in the task event: if the verification is passed, the data identifier and the public key carried in the request are indicated to correspond to the private key for generating the second signature, so that the initiator of the request can be determined to be the second computing engine; otherwise, if the verification is not passed, the request is indicated as a false request, at which point processing of the request may be terminated. On the other hand, the first computing engine needs to determine whether the second computing engine that initiated the request is a legitimate acquirer of the target data, e.g., the first computing engine may query the second computing engine's public key in a locally maintained authorization list for the target data: if the public key of the second computing engine exists in the authorization list, the second computing engine is indicated to have the acquisition authority for the target data, and the request can be normally processed at the moment; otherwise, if the public key of the second computing engine does not exist in the authorization list, it indicates that the second computing engine does not have the acquisition right for the target data, and the processing of the request may be terminated. It should be noted that, in the case of verifying the above-mentioned acquisition right of the second computing engine, it is necessary to process the token acquisition request in the case where the second signature and the acquisition right are simultaneously verified, and one of the two verifies that the request can be terminated without being passed, so as to fully ensure the validity of the processing of the token acquisition request.
In step 305, the first computing engine generates a token and records the generated token in a cache.
At step 306, the first computing engine returns the token generated for it to the second computing engine.
In the case of verification, the first computing engine may generate a token according to the random number, the data identifier, and the public key of the second computing engine, and record the generated token in a cache, e.g., record the token in a token list maintained by the first computing engine. For example, the first computing engine may take a data set of the random number, the data identification, and the public key of the second computing engine as a token, and may then record the token in the token list. For another example, the first computing engine may also take a digest of the data set as a token, and then may record the token in the token list, and generate the random number, the data identification, and the public key for the token. It can be seen that the cache of the first computing engine records the correspondence between the token generated and the random number, the data identifier and the public key that generated the token. The data set may be a simple concatenation or a combination of the above data, which is not limited in the embodiment of the present disclosure. Further, the first computing engine may return the generated token to the second computing engine.
It will be appreciated that the first calculation engine may record in the token list all history tokens that have been generated by itself and that have not been processed (i.e., have not returned corresponding target data or have not been terminated). It should be noted that, in the above step 304, the first computing engine cannot determine whether the received token acquisition request is a replay request yet by verifying the second signature and the acquisition authority of the second computing engine to the target data, so in the case that the token acquisition request initiated by the second computing engine is acquired in step 304, the first computing engine may query whether there is a history token generated according to any random number, the data identifier and the public key of the second computing engine in the token list: if the history token exists, the first computing engine is indicated to have previously processed the same request, so the token acquisition request is a replay request, and processing of the request can be terminated at this time, so as to avoid repeatedly generating a plurality of tokens of the second computing engine aiming at the same target data; otherwise, if the history token does not exist, the first calculation engine may generate a token according to the foregoing steps in response to the token acquisition request. Of course, the token newly generated, after being recorded in the cache, may be used to identify a replay request for the token acquisition request received thereafter.
In step 307, the second compute engine generates a first signature on the received token using its own private key.
In step 308, the second computing engine initiates a data acquisition request containing the token and the first signature to the first computing engine.
In the case of receiving the token returned by the first computing engine, the second computing engine may generate a first signature for the token using its own private key, and may further initiate a data acquisition request including the token and the first signature to the first computing engine.
In step 309, the first computing engine verifies the first signature using the public key of the second computing engine included in the task event and receives the token from the cache query.
In response to a data acquisition request initiated by the second compute engine, the first compute engine may verify the first signature using the public key of the second compute engine contained in the task event and query the received token in the cached historical token. It will be appreciated that if the verification mechanism adopted by the first computing engine for the second signature fails due to an unexpected situation, or if the third party intercepts the token generated by the first computing engine according to the public key of the second computing engine and provided to the second computing engine, the third party needs to generate the first signature using its own private key and include the first signature in the data acquisition request, and send the first signature to the first computing engine, i.e. falsified data acquisition request. Obviously, because the private keys of the third party and the second computing engine are not the same, the first signature cannot pass the verification of the public key of the second computing engine, that is, the first signature can be verified to identify the fake request of the third party for the data acquisition request, so that the request is prevented from being processed by the first computing engine. In addition, if the data acquisition request initiated by the second computing engine to the first computing engine is replayed by the second computing engine or intercepted and replayed by a third party, since the interval time between the replay request and the data acquisition request is generally shorter, the first computing engine can query the token contained in the request according to the cache, so as to determine that the request is a replay request.
Based on this, if the first signature is verified to pass and the token is queried in the cache, it indicates that the initiator of the data acquisition request is indeed the second computing engine corresponding to the token generated by the first computing engine, that is, the request is a real request, and step 310 may be performed at this time; conversely, the first compute engine may terminate processing the data acquisition request if the first signature is verified to fail or the token is not queried in the cache.
At step 310, the first computing engine returns the target data to the second computing engine.
The first computing engine may return the target data via the first node device and the second node device over a common link between the first blockchain node and the second under-chain computing contract.
Alternatively, the first node device and the second node device may also transmit address information of the first computing engine or the second computing engine to each other based on the common link, so as to establish a direct connection channel between the first computing engine and the second computing engine, so that the first computing engine may return the target data to the second computing engine via the direct connection channel. The specific establishment process of the direct connection channel may be referred to the description of the foregoing embodiments, and will not be repeated here. In addition, it should be noted that, the first computing engine and the second computing engine may implement cooperative interaction through a direct communication channel established between the two, for example, the first computing engine may receive the data acquisition request initiated by the second computing engine through the direct communication channel; and/or the first computing engine can return the target data to the first computing engine through the direct-connection channel. The method only needs to transmit address information with smaller data quantity by the common-knowledge link, so that the interference to the original on-link process based on the common-knowledge link is avoided to a certain extent, and the direct connection channel is only used for data transmission between the second computing engine and the second computing engine, so that the possibility of error of target data transmission is reduced.
In step 311, the first computing engine clears the token recorded in the cache.
Under the condition that the token acquisition request is initiated by the second computing engine or the target data is successfully returned to the second computing engine, the first computing engine can clear the token recorded in the cache, so that the token can be used once, and the cache space is saved. Of course, in order to better identify the replay request for the data acquisition request, the token recorded in the above cache may be deleted after determining that the data acquisition request is initiated by the second computing engine or after determining that the target data is successfully returned to the second computing engine, so as to obtain better identification and hit effect for the replay request.
At step 312, the second compute engine performs the under-chain collaboration task using the target data.
The second computing engine can execute the under-chain collaboration task by itself under the condition that the target data returned by the first computing engine is received; alternatively, where the second computing engine allows for invoking other remote computing engines (e.g., the second computing engine is a proxy computing engine deployed in the second node device), the second computing engine may invoke the remote computing engine to perform the chain of collaborative tasks. Similarly, the first computing engine may also execute the task by itself or by invoking a corresponding remote computing engine to execute the task under chain collaboration, which is not described in detail.
At step 313, the second compute engine returns the execution result of the under-chain collaboration task to the second blockchain node.
The second computing engine may return the execution results of the under-chain collaborative task to a second blockchain node. For example, the second computing engine may return the execution result of the under-chain cooperative task to the second scheduling framework, and the second scheduling framework uploads the execution result to the second blockchain node, e.g., may return the execution result to a task instance for the under-chain cooperative task generated in the second blockchain node, thereby completing a complete processing procedure for the under-chain cooperative task. In addition, in the case that the under-chain cooperative task is any sub-task of the under-chain computing task, the second blockchain node may update the task completion status of the under-chain computing task according to the execution result, for example, update the completion status of the sub-task, which is the under-chain cooperative task, to be completed, so as to trigger the under-chain computing task to advance the corresponding workflow, for example, trigger the execution of the next sub-task, and so on.
Fig. 4 is a schematic block diagram of an apparatus according to an exemplary embodiment. Referring to fig. 4, at the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a nonvolatile memory 410, although other hardware required by other services is possible. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 402 reading a corresponding computer program from the non-volatile memory 410 into the memory 408 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.
Fig. 5 is a block diagram of a data processing apparatus according to an exemplary embodiment of the present disclosure, which may be applied to the device shown in fig. 4 to implement the technical solution of the present disclosure. The device is applied to a first computing engine, a first blockchain node is deployed in first node equipment where the first computing engine is located, and a blockchain network where the first blockchain node belongs is deployed with a chain computation contract; the device comprises:
a participant determining unit 501, configured to determine, according to a task event for an under-link collaboration task, a data identifier of each participant of the under-link collaboration task and target data required for executing the under-link collaboration task, where the task event is generated by the under-link computation contract;
a token generating unit 502, configured to generate a token according to the random number, the data identifier, and a public key of the second computing engine, and provide the token to the second computing engine, where the task event indicates that the first blockchain node and the second blockchain node belong to a participant of the under-chain cooperative task, and the second blockchain node and the second computing engine are deployed on a second node device;
A data return unit 503, configured to respond to a data acquisition request including the token and its first signature, and return the target data to a second computing engine for executing the under-chain collaboration task if the token and its first signature indicate that the data acquisition request is initiated by the second computing engine; wherein the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising: the first signature is generated by the second computing engine for the token using its own private key.
Optionally, the under-chain computing contract maintains a task completion state of an under-chain computing task, where the task completion state is used to describe a completion state of each subtask included in the under-chain computing task; in the case that the under-link cooperative task belongs to a subtask of the under-link computation task, the task event is generated by the under-link computation contract in the case that the task completion state satisfies an execution condition of the under-link cooperative task.
Optionally, the task completion status is updated by the under-chain computing contract in response to a transaction corresponding to the under-chain computing task, where the transaction corresponding to the under-chain computing task includes a task creation transaction corresponding to the under-chain computing task, or a result initiated by any node device when executing any of the sub-tasks is completed is returned to the transaction.
Optionally, the participant determining unit 501 is further configured to:
acquiring identity information of each participant from the task event and a data identifier of the target data; or,
and determining the under-chain computing contract according to the task event, and reading the identity information of each participant and the data identification of the target data, which are recorded in the under-chain computing contract, through a first block link point.
Optionally, the token generating unit 502 is further configured to:
and generating a token according to the random number, the data identification and the public key of the second computing engine under the condition that the second computing engine is determined to have the right of acquiring the target data.
Optionally, the first computing engine maintains an authorization list, where the authorization list is used to record identity information of each acquirer allowed to acquire the target data, and the token generating unit 502 is further configured to:
and under the condition that the identity information of the second blockchain node exists in the authorization list or is in a right state, determining that the second blockchain node has the right to acquire the target data.
Optionally, the token generating unit 502 is further configured to:
and responding to the task event, acquiring the data identifier and the public key of the second computing engine from the task event, and generating a token according to the random number and the acquired data identifier and the public key.
Optionally, the task event records a public key of the second computing engine, and the token generating unit 502 is further configured to:
receiving a token acquisition request, wherein the token acquisition request comprises a data identifier of the target data, a public key of an initiator of the token acquisition request and a second signature generated by the initiator on the data identifier and the public key by using a private key of the initiator;
in the event that the second signature passes verification according to the public key of the second calculation engine, a token is generated according to the random number, the data identification and the public key of the initiator.
Optionally, the cache of the first computing engine records the token in the valid state generated by the first computing engine,
the token generation unit 502 is further configured to: if no token which is generated according to any random number, the data identifier and the public key of the second computing engine and is in a valid state exists in the cache, generating a token according to the random number, the data identifier and the public key of the second computing engine;
the apparatus further comprises a token cache unit 504 for: the generated token is recorded in the cache or is set to a valid state in the cache, and the token is deleted in the cache or updated to an invalid state in the event that the data acquisition request is determined to be initiated by a second computing engine or the target data is determined to be successfully returned to the second computing engine.
Optionally, the token buffer unit 504 is further configured to:
in the event that the second signature is determined to be verified by the public key of the second computing engine and the token in a valid state is present in the cache of the first computing engine, determining the token and its first signature indicates that the data acquisition request was initiated by the second computing engine.
Optionally, the token generating unit 502 is further configured to:
and taking the random number, the data identification and the data set formed by the public key of the second computing engine or the digest of the data set as the token.
Optionally, the data return unit 503 is further configured to:
returning the target data to a second compute engine over a consensus link between the first blockchain node and a second blockchain node; or,
and returning the target data to the second computing engine through a direct connection channel between the first computing engine and the second computing engine.
Optionally, the apparatus further includes a channel establishment unit 505 for:
and receiving address information of a second computing engine forwarded by the first node equipment, and establishing the direct connection channel with the second computing engine according to the address information, wherein the address information is sent to the first node equipment by the second node equipment through a consensus link between the first block chain node and the second block chain node under the condition that the task event shows that the first block chain node and the second block chain node are participants of the under-chain cooperation task.
Optionally, the public key of the second compute engine comprises a node public key of the second blockchain node; the device comprises:
fig. 6 is a block diagram of another data processing apparatus according to an exemplary embodiment of the present disclosure, which may be applied to the device shown in fig. 4 to implement the technical solution of the present disclosure. The device is applied to a second computing engine, a second block chain node is deployed in second node equipment where the second computing engine is located, and a chain-down computing contract is deployed in a block chain network where the second block chain node belongs; the device comprises:
a token obtaining unit 601, configured to obtain a token generated by a first computing engine, where the token is generated by the first computing engine according to a random number, a data identifier of target data required for executing the under-chain collaboration task, and a public key of the second computing engine when a task event indicates that a first blockchain node and a second blockchain node belong to a participant of the under-chain collaboration task, and the task event is generated by the under-chain computing contract, where the first blockchain node and the first computing engine are deployed on a first node device;
a data request unit 602, configured to generate a first signature on the token using its own private key, and initiate a data acquisition request including the token and its first signature to a first computing engine, and receive the target data returned by the first computing engine when the token and its first signature indicate that the data acquisition request is initiated by a second computing engine;
And a task execution unit 603, configured to execute the downlink collaborative task according to the target data.
Optionally, the token obtaining unit 601 is further configured to:
initiating a token acquisition request to a first computing engine, wherein the token acquisition request comprises a data identifier of the target data, a public key of a second computing engine and a second signature generated by the second computing engine on the data identifier and the public key by using a private key of the second computing engine;
the token generated and returned by the first computing engine if the second signature passes verification according to the public key of the second computing engine is received.
Optionally, a second scheduling framework is further disposed in the second node device, and the apparatus further includes:
a task receiving unit 604, configured to receive the downlink collaborative task that is distributed to the first computing engine by the second scheduling framework in response to the monitored task event.
Optionally, the under-chain collaboration 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 under-chain collaboration task.
Optionally, the task execution unit 603 is further configured to:
the second computing engine itself performs the under-chain collaboration task; or,
The second computing engine invokes the remote computing engine to perform the chain of collaborative tasks.
Optionally, the method further comprises:
a first returning unit 605, configured to return, by the second node device, an execution result of the under-link collaboration task to the second computing node; or,
and a second returning unit 606, configured to return, when the under-chain cooperative task is distributed to the second computing engine by the second scheduling frame corresponding to the second blockchain node, an execution result of the under-chain cooperative task to the second computing node through the second scheduling frame.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expremmion Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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 (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, this specification does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Although one or more embodiments of the present description provide method operational steps as 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 recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.
For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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 means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.
Claims (24)
1. The data processing method is applied to a first computing engine, a first blockchain node is deployed in first node equipment where the first computing engine is located, and a blockchain network where the first blockchain node belongs is deployed with a downlink computing contract; the method comprises the following steps:
determining each participant of the under-link collaboration task and a data identifier of target data required for executing the under-link collaboration task according to a task event for the under-link collaboration task, wherein the task event is generated by the under-link computation contract;
generating a token according to the random number, the data identifier and a public key of a second computing engine and providing the token to the second computing engine, wherein the second blockchain node and the second computing engine are deployed on second node equipment under the condition that the task event indicates that the first blockchain node and the second blockchain node belong to participants of the under-chain cooperative task;
In response to a data acquisition request containing the token and its first signature, returning the target data to a second computing engine for performing the under-chain collaborative task if the token and its first signature indicate that the data acquisition request was initiated by the second computing engine; wherein the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising: the first signature is generated by the second computing engine for the token using its own private key.
2. The method of claim 1, the under-chain computing contract maintaining a task completion status of an under-chain computing task, the task completion status describing completion status of each subtask contained by the under-chain computing task; in the case that the under-link cooperative task belongs to a subtask of the under-link computation task, the task event is generated by the under-link computation contract in the case that the task completion state satisfies an execution condition of the under-link cooperative task.
3. The method of claim 2, the task completion status updated by the under-chain computing contract in response to a transaction corresponding to the under-chain computing task, wherein the transaction corresponding to the under-chain computing task comprises a task creation transaction corresponding to the under-chain computing task or a result return transaction initiated by any node device upon completion of execution of any of the sub-tasks.
4. The method of claim 1, the determining, from task events for an under-chain collaboration task, data identifications of respective participants of the under-chain collaboration task and target data required to perform the under-chain collaboration task, comprising:
acquiring identity information of each participant from the task event and a data identifier of the target data; or,
and determining the under-chain computing contract according to the task event, and reading the identity information of each participant and the data identification of the target data, which are recorded in the under-chain computing contract, through a first block link point.
5. The method of claim 1, the generating a token from the random number, the data identification, and a public key of a second compute engine, comprising:
and generating a token according to the random number, the data identification and the public key of the second computing engine under the condition that the second computing engine is determined to have the right of acquiring the target data.
6. The method of claim 5, the first computing engine maintaining an authorization list for recording identity information of each acquirer that is permitted to acquire the target data, the determining that the second blockchain node has authority to acquire the target data comprising:
And under the condition that the identity information of the second blockchain node exists in the authorization list or is in a right state, determining that the second blockchain node has the right to acquire the target data.
7. The method of claim 1, the generating a token from the random number, the data identification, and a public key of a second compute engine, comprising:
and responding to the task event, acquiring the data identifier and the public key of the second computing engine from the task event, and generating a token according to the random number and the acquired data identifier and the public key.
8. The method of claim 1, wherein the task event records a public key of a second computing engine, wherein the generating a token from the random number, the data identification, and the public key of the second computing engine comprises:
receiving a token acquisition request, wherein the token acquisition request comprises a data identifier of the target data, a public key of an initiator of the token acquisition request and a second signature generated by the initiator on the data identifier and the public key by using a private key of the initiator;
in the event that the second signature passes verification according to the public key of the second calculation engine, a token is generated according to the random number, the data identification and the public key of the initiator.
9. The method of claim 1, wherein the first computing engine generates a token in a valid state in a cache of the first computing engine,
the generating a token from the random number, the data identification, and the public key of the second computing engine comprises: if no token which is generated according to any random number, the data identifier and the public key of the second computing engine and is in a valid state exists in the cache, generating a token according to the random number, the data identifier and the public key of the second computing engine;
the method further comprises the steps of: the generated token is recorded in the cache or is set to a valid state in the cache, and the token is deleted in the cache or updated to an invalid state in the event that the data acquisition request is determined to be initiated by a second computing engine or the target data is determined to be successfully returned to the second computing engine.
10. The method of claim 9, the determining that the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising:
in the event that the second signature is determined to be verified by the public key of the second computing engine and the token in a valid state is present in the cache of the first computing engine, determining the token and its first signature indicates that the data acquisition request was initiated by the second computing engine.
11. The method of claim 1, the generating a token from the random number, the data identification, and a public key of a second compute engine, comprising:
and taking the random number, the data identification and the data set formed by the public key of the second computing engine or the digest of the data set as the token.
12. The method of claim 1, the returning the target data to a second computing engine, comprising:
returning the target data to a second compute engine over a consensus link between the first blockchain node and a second blockchain node; or,
and returning the target data to the second computing engine through a direct connection channel between the first computing engine and the second computing engine.
13. The method of claim 12, the direct channel being established by:
and receiving address information of a second computing engine forwarded by the first node equipment, and establishing the direct connection channel with the second computing engine according to the address information, wherein the address information is sent to the first node equipment by the second node equipment through a consensus link between the first block chain node and the second block chain node under the condition that the task event shows that the first block chain node and the second block chain node are participants of the under-chain cooperation task.
14. The method of any of claims 1-13, the public key of the second compute engine comprising a node public key of the second blockchain node.
15. The data processing method is applied to a second computing engine, a second blockchain node is deployed in second node equipment where the second computing engine is located, and a blockchain network where the second blockchain node belongs is deployed with a chain computation contract; the method comprises the following steps:
obtaining a token generated by a first computing engine, wherein the token is generated by the first computing engine according to a random number, a data identifier of target data required for executing the under-chain cooperation task and a public key of the second computing engine under the condition that a task event shows that a first blockchain node and a second blockchain node belong to a participant of the under-chain cooperation task, the task event is generated by the under-chain computing contract, and the first blockchain node and the first computing engine are deployed on first node equipment;
generating a first signature on the token by using a private key of the first computing engine, initiating a data acquisition request containing the token and the first signature thereof to the first computing engine, and receiving target data returned by the first computing engine when the token and the first signature thereof indicate that the data acquisition request is initiated by a second computing engine;
And executing the under-chain cooperation task according to the target data.
16. The method of claim 15, the obtaining a token generated by a first computing engine, comprising:
initiating a token acquisition request to a first computing engine, wherein the token acquisition request comprises a data identifier of the target data, a public key of a second computing engine and a second signature generated by the second computing engine on the data identifier and the public key by using a private key of the second computing engine;
the token generated and returned by the first computing engine if the second signature passes verification according to the public key of the second computing engine is received.
17. The method of claim 15, wherein a second scheduling framework is further deployed in the second node device, the under-chain collaboration task being obtained by:
the method further includes receiving the under-chain collaborative task distributed by a second scheduling framework to the first computing engine in response to the monitored task event.
18. The method of claim 17, the under-chain collaboration task being distributed by a second scheduling framework to a second computing engine if a computing type of the second computing engine matches a task type of the under-chain collaboration task.
19. The method of claim 15, the performing the under-chain collaboration task comprising:
The second computing engine itself performs the under-chain collaboration task; or,
the second computing engine invokes the remote computing engine to perform the chain of collaborative tasks.
20. The method of claim 15, further comprising:
returning an execution result of the under-chain cooperative task to a second computing node through second node equipment; or,
and returning an execution result of the under-chain cooperative task to the second computing node through the second scheduling frame under the condition that the under-chain cooperative task is distributed to the second computing engine by the second scheduling frame corresponding to the second blockchain node.
21. The data processing device is applied to a first computing engine, a first blockchain node is deployed in first node equipment where the first computing engine is located, and a blockchain network where the first blockchain node belongs is deployed with a downlink computing contract; the device comprises:
a participant determining unit, configured to determine, according to a task event for an under-link collaboration task, a data identifier of each participant of the under-link collaboration task and target data required for executing the under-link collaboration task, where the task event is generated by the under-link computation contract;
the token generation unit is used for generating a token according to the random number, the data identifier and the public key of the second computing engine and providing the token to the second computing engine when the task event indicates that the first blockchain node and the second blockchain node belong to the participants of the under-chain cooperative task, and the second blockchain node and the second computing engine are deployed on second node equipment;
A data return unit for returning the target data to a second computing engine for executing the under-chain collaborative task in response to a data acquisition request including the token and its first signature, in the event that the token and its first signature indicate that the data acquisition request was initiated by the second computing engine; wherein the token and its first signature indicate that the data acquisition request was initiated by a second computing engine, comprising: the first signature is generated by the second computing engine for the token using its own private key.
22. The data processing device is applied to a second computing engine, a second blockchain node is deployed in second node equipment where the second computing engine is located, and a blockchain network where the second blockchain node belongs is deployed with a downlink computing contract; the device comprises:
the token acquisition unit is used for acquiring a token generated by the first computing engine, wherein the token is generated by the first computing engine according to a random number, a data identifier of target data required for executing the under-chain cooperation task and a public key of the second computing engine when a task event shows that a first blockchain node and a second blockchain node belong to a participant of the under-chain cooperation task, the task event is generated by the under-chain computing contract, and the first blockchain node and the first computing engine are deployed on first node equipment;
A data request unit, configured to generate a first signature on the token using a private key of the first computing engine, initiate a data acquisition request including the token and a first signature thereof to a first computing engine, and receive the target data returned by the first computing engine when the token and the first signature thereof indicate that the data acquisition request is initiated by a second computing engine;
and the task execution unit is used for executing the under-chain cooperative task according to the target data.
23. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured to implement the method of any one of claims 1-20 by executing the executable instructions.
24. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-20.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210343989.0A CN114726537B (en) | 2022-03-31 | 2022-03-31 | Data processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210343989.0A CN114726537B (en) | 2022-03-31 | 2022-03-31 | Data processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114726537A CN114726537A (en) | 2022-07-08 |
| CN114726537B true CN114726537B (en) | 2024-03-26 |
Family
ID=82241372
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210343989.0A Active CN114726537B (en) | 2022-03-31 | 2022-03-31 | Data processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114726537B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110457875A (en) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | Data grant method and device based on block chain |
| CN111447073A (en) * | 2020-03-31 | 2020-07-24 | 河北大学 | Identity management and authentication system and method based on block chain and zero-knowledge proof |
| CN112907375A (en) * | 2021-03-25 | 2021-06-04 | 平安科技（深圳）有限公司 | Data processing method, data processing device, computer equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10880074B2 (en) * | 2018-10-15 | 2020-12-29 | Adobe Inc. | Smart contract platform for generating and customizing smart contracts |
-
2022
- 2022-03-31 CN CN202210343989.0A patent/CN114726537B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110457875A (en) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | Data grant method and device based on block chain |
| CN111447073A (en) * | 2020-03-31 | 2020-07-24 | 河北大学 | Identity management and authentication system and method based on block chain and zero-knowledge proof |
| CN112907375A (en) * | 2021-03-25 | 2021-06-04 | 平安科技（深圳）有限公司 | Data processing method, data processing device, computer equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114726537A (en) | 2022-07-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Schmidt | Middleware for real-time and embedded systems | |
| TW202213217A (en) | Secure service request processing methods and apparatuses | |
| WO2023207078A1 (en) | Data processing method and apparatus, electronic device, and storage medium | |
| CN110599144B (en) | Network access method and device for blockchain nodes | |
| CN113722114A (en) | Data service processing method and device, computing equipment and storage medium | |
| CN114710492B (en) | Method and device for establishing direct connection channel, electronic equipment and storage medium | |
| CN113935737A (en) | Random number generation method and device based on block chain | |
| CN112291321B (en) | Service processing method, device and system | |
| WO2023185041A1 (en) | Data processing method and apparatus, electronic device, and storage medium | |
| CN116305298B (en) | Method and device for managing computing power resources, storage medium and electronic equipment | |
| CN114726537B (en) | Data processing method and device | |
| WO2024066005A1 (en) | Method and apparatus for replaying blockchain transaction | |
| CN114692185A (en) | Data processing method and device | |
| CN114710350B (en) | Method and device for distributing callable resources, electronic equipment and storage medium | |
| CN114896635A (en) | Data processing method and device, electronic equipment and storage medium | |
| CN116244062A (en) | Data processing method and device, electronic equipment and storage medium | |
| CN114741736A (en) | Data processing method and device, electronic equipment and storage medium | |
| CN114782016A (en) | Creditor data processing method and device based on intelligent contract and block chain system | |
| CN114338124A (en) | Management method and system of cloud password computing service, electronic device and storage medium | |
| CN111062814A (en) | Resource transfer method, device and system based on block chain | |
| CN115022305B (en) | Data transmission system, method, device, equipment and medium | |
| CN113761496B (en) | Identity verification method and device based on blockchain and electronic equipment | |
| CN113673844B (en) | Information feedback method, device and equipment | |
| LU101121B1 (en) | Method for improving blockchain applications | |
| CN117527319A (en) | Business handling method, device and equipment based on block chain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |