CN113098983B

CN113098983B - Task execution method and device based on intelligent contract

Info

Publication number: CN113098983B
Application number: CN202110611540.3A
Authority: CN
Inventors: 赵博然
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2021-10-15
Anticipated expiration: 2041-06-02
Also published as: CN114116166A; CN113098983A

Abstract

One or more embodiments of the present specification provide a method and an apparatus for task execution based on an intelligent contract. The method is applied to first node equipment deployed with block link point instances and service instances, and comprises the following steps: the block chain node instance responds to a first transaction for calling a workflow defined in an intelligent contract, and generates a task allocation event corresponding to a first task node under the condition that the processing progress of the workflow is before the first task node and the execution condition of the first task node is met by the access provided by the first transaction; the service instance executes a first contract task if the task allocation event is monitored and the first contract task contained in the task allocation event is determined to be allocated to a first blockchain member to which the first node device belongs.

Description

Task execution method and device based on intelligent contract

Technical Field

One or more embodiments of the present disclosure relate to the field of block chain technologies, and in particular, to a method and an apparatus for task execution based on an intelligent contract.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Nodes in the blockchain network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data. In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their related data, so that blockchain subnets can be further established on the basis of blockchain main networks.

The intelligent contract deployed in the block chain main network or the block chain sub network can define a workflow, so that the block chain nodes can execute contract tasks corresponding to the task nodes in the workflow in the process of executing the intelligent contract. However, a plurality of contract tasks corresponding to the same intelligent contract may respectively need different block chain members to participate in execution, so that how to allocate the block chain members to participate in executing the corresponding contract tasks in order is an urgent problem to be solved in the intelligent contract execution process when the intelligent contract is called.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for task execution based on an intelligent contract.

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 specification, a task execution method based on an intelligent contract is provided, which is applied to a first node device deployed with block-linked node instances and service instances, and includes:

the block chain node instance responds to a first transaction for calling a workflow defined in an intelligent contract, and generates a task allocation event corresponding to a first task node under the condition that the processing progress of the workflow is before the first task node and the execution condition of the first task node is met by the access provided by the first transaction;

the service instance executes a first contract task if the task allocation event is monitored and the first contract task contained in the task allocation event is determined to be allocated to a first blockchain member to which the first node device belongs.

According to a second aspect of one or more embodiments of the present specification, there is provided a task execution device based on an intelligent contract, applied to a first node device deployed with block-linked node instances and service instances, the device including:

the event generating unit enables the block link point instance to respond to a first transaction for calling a workflow defined in an intelligent contract and generate a task distribution event corresponding to a first task node under the condition that the processing progress of the workflow is before the first task node and the execution condition of the first task node is met by the access provided by the first transaction;

and the task execution unit enables the business instance to execute the first contract task under the condition that the task distribution event is monitored and the first contract task contained in the task distribution event is determined to be distributed to the first blockchain member to which the first node equipment belongs.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

Drawings

FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.

Fig. 4 is a schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

FIG. 5 is a flowchart of a method for intelligent contract-based task execution, according to an exemplary embodiment.

FIG. 6 is a workflow diagram of an intelligent contract provided by an exemplary embodiment.

FIG. 7 is a workflow state transition diagram for an intelligent contract provided by an exemplary embodiment.

Fig. 8 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

FIG. 9 is a block diagram of a task execution device based on smart contracts provided by an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds the byte code, and the to field of the transaction is empty. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account of the initiator of the transaction (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract being invoked, and the value field is the value in EtherFang that is kept in the data field of the transaction as the method and parameters for invoking the smart contract. After invoking the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance through a blockchain node (e.g., node 6 in fig. 2). The intelligent contract is independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. To create an intelligent contract in an ethernet workshop, the intelligent contract needs to be compiled, compiled into byte codes, deployed to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, and the intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet workshop network.

It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchain networks may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). In addition to EVM in the ethernet, different blockchain networks may employ various virtual machines, which is not limited herein.

After executing a transaction that invokes a smart contract, a node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the smart contract. In this way, information about the contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can implement message passing through events in the receipt to trigger the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to ensure that the consensus mechanism is the aforementioned mechanism. For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

Due to the decentralized characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same blockchain data, and the special requirements of part of nodes cannot be met. Taking a federation chain as an example, all federation members (i.e., node members in a federation) may form a blockchain network, and all federation members respectively have corresponding blockchain nodes in the blockchain network, and may obtain all transactions and related data occurring on the blockchain network through the corresponding blockchain nodes. In some cases, however, there may be some security-required transactions that some coalition members wish to complete, which may both wish to be able to verify on the blockchain or to take advantage of other advantages of blockchain technology, and avoid other coalition members from viewing the transactions and associated data. Although the federating members can additionally build a new blockchain network in a manner similar to the blockchain network including all federating members described above, the new blockchain network is built from scratch, which consumes a lot of resources and is time-consuming in both the building process and the post-building configuration process. The demand between the members of the federation is often temporary or has a certain timeliness, so that the newly-built blockchain network can quickly lose significance due to the disappearance of the demand, thereby further increasing the link establishment cost of the blockchain network. The demands among the federation members often change, and the federation members corresponding to each demand often differ, so that a new blockchain network may need to be established whenever a change occurs in a federation member, thereby causing a great waste of resources and time.

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of the blockchain master network. Then, in a federation chain scenario such as that described above, federation members can build the required blockchain subnets on a blockchain master basis based on their own needs, already participating in the blockchain master. Because the block chain sub-networks are established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-networks are greatly reduced in consumed resources, required time consumption and the like, and are extremely high in flexibility.

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each main network node in the block chain main network respectively acquires transactions for establishing a block chain sub-network, wherein the transactions comprise configuration information of the block chain sub-network, and the configuration information comprises identity information of node members. Then, each main network node in the block chain main network executes the transaction respectively; when the first main network node belongs to the node member indicated by the configuration information, the node device deploying the first main network node generates an creation block containing the configuration information based on the transaction and starts a first sub-network node belonging to the block chain sub-network.

The transaction for establishing the blockchain sub-network can be initiated by an administrator of the blockchain main network, that is, the administrator is only allowed to establish the blockchain sub-network on the basis of the blockchain main network, and the establishment permission of the blockchain sub-network is prevented from being opened to a common user, so that the security problem caused by the establishment permission can be prevented. In some cases, a common user of the blockchain main network may also be allowed to initiate a transaction for building the blockchain sub-network, so as to meet networking requirements of the common user, and the common user can still quickly build the blockchain sub-network under the condition that an administrator is not convenient to initiate the transaction.

For example, as shown in fig. 4, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Assume nodeA, nodeB, nodeC, and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet can be initiated by nodeA to subnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain subnet, nodeb a to nodeb d need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain subnet to subnet 0; if the node E is an administrator but allows a common user to initiate the transaction of building the blockchain sub-network, the node A-node E can initiate the transaction of building the blockchain sub-network to the subnet 0. Of course, the blockchain link point initiating the transaction for building the blockchain subnet does not necessarily participate in the built blockchain subnet, regardless of the administrator or the general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to subnet0, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

When the blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when a blockchain subnet1 is established on the subnet0 shown in fig. 4, it can be considered that the subnet0 is at the first layer, the subnet1 is at the second layer, the subnet0 is the parent network of the subnet1, and the subnet1 is the subnet 0. And the blockchain sub-network may also constitute a corresponding blockchain sub-network, for example, another blockchain sub-network bnet3 may be further constituted on the basis of the sub-net 1 in fig. 4, at this time, it may be considered that the sub-net is in the third layer, the sub-net 1 is the parent network corresponding to the sub-net 3, the sub-net 3 is the subnet of the sub-net 1, and the sub-net 3 is the grandchild network of the sub-net 0, similarly, the sub-net 3 may still newly constitute the blockchain sub-network on the basis thereof, so that such a multi-level tree structure is formed between the blockchain networks, and in this specification, any blockchain network is managed by its corresponding parent network, that is, managed by the blockchain network constituting any blockchain network of the blockchain network, so that in the blockchain sub-network as shown in fig. 4, the main level of the blockchain is the root network, and each blockchain sub-network is the corresponding tree node sub-chain sub-network of the other blockchain sub-network, and its corresponding system is represented by any blockchain sub-chain sub-network of the blockchain system, as a specific example, when the block chain master network is a bottom layer block chain network, the block chain master network is managed by the block chain master network itself. The block chain master network in this specification may be a bottom layer block chain network, where the bottom layer block chain network refers to a block chain sub-network that is not established on the basis of other block chain networks, and therefore there is no other block chain network except the block chain master network and the block chain master network can manage the block chain master network, for example, the subnet0 in fig. 4 may be considered as a block chain master network belonging to a bottom layer block chain network type, and the subnet0 manages the subnet0 itself, and of course, the block chain master network may also be a sub-network of another block chain network, which is not limited in this specification. The block chain network tree system realizes layer-by-layer management by managing the corresponding child nodes through the father nodes, reduces the management pressure of the block chain main network, and simultaneously avoids exposing subnet information of an upper network to a lower network, thereby realizing the secret management of networks at all levels.

After the transaction for establishing the blockchain sub-network is sent to the blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, and is not limited by the present specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of the node members.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When the blockchain subnet is established, the first master network node does not directly join the blockchain subnet to become a node member of the blockchain subnet, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member of the blockchain subnet. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub-network node belongs to a blockchain sub-network, so that the blockchain member can participate in the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node device, so that mutual isolation between the storages used by the first main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

It can be seen that the first master network node and the first sub-network node are logically divided block chain link points, and from the perspective of physical devices, the node devices which are equivalent to the first master network node and the first sub-network node are deployed to participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the first main network node and the first sub-network node may adopt the same public key, the first main network node and the first sub-network node should be regarded as different blockchain nodes. For example, in fig. 4, the nodeA in subnet0 corresponds to a first master network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a first sub-network node. It can be seen that, since the identity systems are independent of each other, even if the public key adopted by the first subnet node is different from that of the first master network node, the implementation of the solution in this specification is not affected.

Of course, the node members of the blockchain sub-network are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet may be completely consistent with the node members of the blockchain main network, and at this time, all the blockchain members may obtain data on the blockchain main network and the blockchain subnet, but data generated by the blockchain main network and the blockchain subnet may still be isolated from each other, for example, one type of service may be implemented on the blockchain main network, and another type of service may be implemented on the blockchain subnet, so that service data generated by the two types of services may be isolated from each other.

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets established on the blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as the administrator; the administrators of the blockchain main network and the blockchain sub-network may be the same or different.

One of the advantages of building the blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited by the attribute configuration of the first main network node and is not related to the first main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet include transactions that invoke contracts. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

the from field is information of the initiator of the transaction, such as administeror indicating that the initiator is an Administrator; the to field is the address of the intelligent contract being called, for example, the intelligent contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method used in the Subnet contract to build the blockchain Subnet may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by the aforementioned example, which is specifically the aforementioned configuration information.

Take the example that nodes nodeA-nodeS on Subnet0 execute a transaction that invokes the AddSubnet () method in the Subnet contract. After the transaction passes the consensus, nodeA-nodeE respectively execute the AddSubnet () method and transmit configuration information to obtain corresponding execution results.

The execution result of the contract may include the configuration information, and the execution result may be in the receipt as described above, and the receipt may contain the event related to the execution of the adsubnet () method, i.e., the networking event. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, nodeA to nodeE can determine to monitor the event related to executing the AddSubnet () method, that is, the networking event, when the topic including the keyword subnet is monitored by monitoring topic included in each event in the generated receipt. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the nodeA-nodeE monitors the 1 st event, the event is determined to be irrelevant to the AddSubnet () method because the contained topic content is other; and when the 2 nd event is monitored by the nodeA to nodeE, determining that the event is related to the AddSubnet () method because the contained topic content is subnet, and further reading a data field corresponding to the event, wherein the data field comprises the configuration information. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

the public key of nodeA, the IP of nodeA, port number … of nodeA;

public key of nodeB, IP of nodeB, port number … of nodeB;

public key of nodeC, IP of nodeC, port number … of nodeC;

the public key of nodeD, the IP of nodeD, port number … of nodeD;

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, nodeA-nodeE can determine whether the subnet1 already exists according to the recorded network identifiers of all the created subnet block chains; if not, subnet1 is the new blockchain subnet that needs to be created currently, and if so, subnet1 is already present.

In addition to the network identifier of the new blockchain subnet that is desired to be created, a predefined new network identifier may be used, which indicates that the corresponding networking event is used to create the new blockchain subnet. For example, the subnet1 may be replaced by newsbnet, where newsbnet is a predefined new network identifier, and when the nodeA to nodeE recognize that the data field includes newsbnet, it may be determined that an event including newsbnet is a networking event and a new blockchain subnet needs to be created.

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. For example, when determining that subnet1 is a blockchain subnet that needs to be newly built, nodeA to nodeE further identify the identity information of the node members included in the data field to determine their own processing methods. For example, the nodeA to nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, and assume that nodeA to nodeD are respectively deployed on node devices 1 to 4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so as to become a subnet node of subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first master network node and the first subnet node do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information previously generated for nodeA 1-nodeD 1, and is different from the identity information of nodeA-nodeD. Still taking nodeA as an example, if identity information of nodeA1 is found in the data field, nodeA triggers node device 1 to generate a birth block, deploy nodeA1, and load the birth block by nodeA 1; the nodeB-nodeD processing modes are similar, and are not described in detail here.

In addition to configuration information, the execution results of the contract may include a foundational block. In other words, in addition to the configuration information contained in the data field, the created block containing the configuration information may be directly generated in the process of executing the contract call, so that the created block is contained in the data field, and for the nodeA to nodeD described above, the corresponding node devices 1 to 4 may directly obtain the created block from the data field through a message mechanism without self-generation, so that the deployment efficiency of nodeA1 to nodeD1 may be improved.

In this specification, the transaction for creating the blockchain subnet may not be a transaction for calling an intelligent contract, so that the blockchain network that does not support the intelligent contract may also implement the technical solution of this specification, thereby quickly creating the blockchain subnet on the basis of the blockchain main network. For example, a group network transaction type identifier may be predefined, and when a transaction includes the group network transaction type identifier, it indicates that the transaction is used for building a new blockchain subnet, that is, the transaction is a transaction for building a blockchain subnet. The blockchain platform code may include related processing logic for constructing a blockchain sub-network, so that when a first master network node running the blockchain platform code performs a transaction, if the transaction is found to include the networking transaction type identifier and the first master network node belongs to a node member indicated by configuration information in the transaction, a node device deploying the first master network node may be triggered to generate an innovation block including the configuration information and start the first sub-network node based on the processing logic, and the innovation block is loaded by the first sub-network node to form the blockchain node in the blockchain sub-network.

The node device is equivalent to deploying a blockchain node on the node device by pulling up a process and creating an instance in the process, and running blockchain platform code by the instance. For the first master network node, a first instance is created by the node device in the above process and formed by the first instance running blockchain platform code. Similarly, for the first subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. When the first instance and the second instance are located in the same process, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved; of course, the second instance may be in a different process on the node device than the first instance, and this specification does not limit this. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on any node device, blocks generated by each block link point deployed on any node device are respectively stored in different storages (for example, a database) on any node device, and the storages used by each block link point deployed on any node device are isolated from each other.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 4 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA1, nodeA2, nodeB1, nodeB2, nodeC1, nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as a blockchain main network, and a blockchain subnet is further constructed on the basis, for example, a blockchain subnet3 is constructed on the basis of subnet1, the process is similar to the construction of subnet1 or subnet2, only the blockchain is replaced by a main blockchain subnet1, which is not described herein, and finally, the subnet3 includes nodeA3, nodeB3 and nodeC3, so that nodeA and nodeA1, nodeA2, nodeA3, nodeB and nodeB1, nodeB2, nodeB3, nodeC and nodeC1, nodeC2 and nodeC3 are respectively deployed on the same node device.

For any blockchain network established in the foregoing manner (such as the above-mentioned blockchain main network or blockchain sub-network), an intelligent contract can be deployed thereon, and contract codes (such as byte codes) of the intelligent contract run in the virtual machines of the respective blockchain nodes constituting the blockchain network in a distributed manner. An intelligent contract deployed in a blockchain network may define a workflow including task nodes, and a dependency relationship may exist in a contract task corresponding to each of the task nodes in an execution process. If the dependency relationship exists between any two contract tasks, the two contract tasks are in a serial relationship; alternatively, if the dependency does not exist between any two contract tasks.

For the intelligent contract defined with the workflow, the contract execution process is the process of executing each contract task in the workflow. In addition, because a plurality of contract tasks corresponding to the same intelligent contract may respectively need different block chain members to participate in execution, to implement the preset function of the intelligent contract, it is necessary to reasonably distribute the block chain members to participate in executing the corresponding contract tasks in order.

Therefore, the specification provides a task execution method based on an intelligent contract. Under the condition that each contract task contained in the workflow defined by the intelligent contract needs different block chain members to participate in execution, the method can accurately distribute the block chain members to execute the corresponding contract tasks, thereby ensuring the correct execution of the intelligent contract and realizing the corresponding contract function. The task execution scheme of the intelligent contract of the present specification is described below with reference to fig. 5.

Referring to fig. 5, fig. 5 is a flowchart of a task execution method based on an intelligent contract according to an exemplary embodiment. As shown in fig. 5, the method is applied to a first node device deployed with a block-link node instance and a service instance, and may include the following steps:

in step 502, the block link point instance responds to a first transaction calling a workflow defined in the intelligent contract, and generates a task allocation event corresponding to the first task node under the condition that the processing progress of the workflow is before the first task node and the access provided by the first transaction enables the execution condition of the first task node to be met.

Firstly, it should be noted that a blockchain platform code is deployed in the node device described in this specification, and a blockchain link point example is locally formed in a process of the node device running the platform code; in addition, a blockchain service code is also deployed in the node device, and a service instance is locally formed in the process of running the service code by the node device. The blockchain network to which the blockchain link point instance deployed in the node device belongs may be a blockchain main network or a blockchain sub-network established in the foregoing manner, and of course, may also be applied to an independent blockchain network (i.e., the blockchain network is not established based on other blockchain networks, and there is no other blockchain network established based on the blockchain network). In other words, the task execution method based on the intelligent contract described in this specification may be applied to any blockchain network, and the mutual relationship between this blockchain network and other blockchain networks is not limited in this specification.

In the process of deploying the block chain node instance and the service instance, the node device can respectively pull up a plurality of processes, and respectively run the block chain platform code and the block chain service code in different processes, so that the block chain node instance and the service instance are respectively deployed in different processes, and correspondingly, the block chain node instance and the service instance can realize data transmission through cross-process interaction. By the method, the block link point instance and the service instance are guaranteed to generate less interference in the operation process, and fault isolation among different instances is achieved. Alternatively, in order to reduce the delay possibly generated in the cross-process interaction process to ensure the task execution efficiency in the intelligent contract execution process, the node device may also deploy the block link point instance and the service instance in the same process, which is not limited in this specification.

In addition, only one block link point instance belonging to the above block chain network may be deployed in the node device, multiple block link point instances belonging to the same block chain network may also be deployed at the same time, and multiple block chain node instances belonging to different block chain networks may also be deployed (of course, this scheme only focuses on the execution process of a block link point instance belonging to a certain block chain network on an intelligent contract deployed in the block chain network), and the number of block link point instances deployed in the node device is not limited in this specification.

As previously described, intelligent contracts deployed in blockchain networks may be invoked and executed by blockchain transactions issued by any blockchain node. Further, a plurality of tasks may need to be executed in the execution process of the intelligent contract, so a workflow corresponding to each task may be defined in the intelligent contract, where each task has a corresponding task node. The process of executing the intelligent contract is the process of sequentially executing each contract task defined in the workflow, and the execution of the contract tasks causes the working state of the intelligent contract to generate state transition among each task node according to the preset sequence of the workflow. The workflow may be invoked by a blockchain exchange, so that, in response to a first transaction invoking the workflow defined in the intelligent contract, a blockchain link point instance deployed in the node device may generate a task allocation event corresponding to the first task node in a case where a processing progress of the workflow is before the first task node and an entry provided by the first transaction enables an execution condition of the first task node to be satisfied.

Taking the blockchain network shown in fig. 4 as an example, in the blockchain master network subnet0, the node devices where the respective blockchain link points in the network belong to the corresponding blockchain members, respectively, for example, in the case where subnet0 is a federation chain, a blockchain link point a, a blockchain link point B, a blockchain link point C, a blockchain link point D, and a blockchain node E may correspond to different federation chain members, respectively. The following describes in detail the execution process of each contract task in the intelligent contract execution process, taking the example that the intelligent contract defined with workflow is deployed in the blockchain main network subnet0, and the corresponding intelligent contract execution process may be referred to in fig. 6.

The intelligent contract with workflow is defined, and a calling method with a preset calling form can be provided externally, for example, the method can be:

void transit(Event ev)

wherein, the definition of the Event is as follows:

class Event {

String type,

Bytes args,

}

where event _ type identifies the type of this event and args is a parameter of this event. Therefore, the first transaction can call the intelligent contract through the transit of the method, and then call of the workflow is achieved.

As shown in FIG. 6, the workflow defined in the intelligent contract includes a total of 4 contract tasks: contract task A, contract task B1, contract task B2, and contract task C. Any task corresponds to a corresponding task node, and the task node corresponding to any contract task may be considered as an execution starting point of the contract task, for example, the task node a, the task node B1, the task node B2, and the task node C in fig. 6 may be respectively used as an execution starting point of the contract task a, the contract task B1, the contract task B2, and the contract task C. In addition, both the contract task B1 and the contract task B2 need to take the execution result of the contract task a as an entry, so the contract task B1 and the contract task B2 have a dependency relationship with respect to the contract task a, that is, the contract task B1 and the contract task a, and the contract task B1 and the contract task a are in a serial relationship. Since there is no dependency between contract task B1 and contract task B2, there is a parallel relationship between contract task B1 and contract task B2. Therefore, in the execution process of the intelligent contract, only after the execution of the contract task A is finished (the execution result of the contract task A is obtained), the contract task B1 and the contract task B2 are executed; the relative order of executing the contract task B1 and the contract task B2 is not limited, and after executing the contract task a, the contract task B2 may be executed after executing the contract task B1, the contract task B1 may be executed after executing the restrictive contract task B2, and the service instance 1 and the contract task B2 may be executed at the same time, which is not described again. The contract task A can be defined in the intelligent contract in the following mode:

class TaskA public Task {// Task name "A"

void Execute(Bytes args) {

task specific logics

auto task_args = ParseAndConstructTaskArgs(args);

EmitEvent({

Task _ id = "a",// task name

Task _ type = task _ type,// event type of task assignment event

Task _ args = task _ args,// parameter of task assignment event

Org _ id = org _ id _ of _ a,// node device identification

});

}

In addition, the contract tasks B1, B2, and C are defined in a manner similar to that of contract task A and are not listed. Of course, the number of contract tasks in the intelligent contract and the serial and parallel relationships between the contract tasks are not limited in the present specification.

Because the intelligent contract is deployed in the subnet0, each partition link point in the subnet0 executes the workflow, and to reduce the contract execution cost, any one of the contract tasks may be allocated to a part of federation chain members, so that the node devices corresponding to the part of federation chain members execute the contract task, and the execution result of the corresponding contract task or intelligent contract may be synchronized to other partition chain nodes in the subnet0, so as to avoid resource waste caused by the repeated execution of the contract task by each node member.

In an embodiment, the execution condition of the first task node may be that a data format of the entry provided by the first transaction meets requirements. As described in the embodiment of fig. 6, assuming that the first transaction calls the workflow to start executing the contract task a, that is, the first task node is the task node a corresponding to the contract task a, the entries provided by the first transaction may be event type in the form of String (String) and parameter args in the form of Bytes (Bytes). Therefore, the node device may determine that the entry provided by the first transaction satisfies the execution condition when determining that the data format of the event type and the parameter conforms to the specified format of the called method. It can be seen that, if the processing progress of the workflow at the current time is before the task node a (e.g. at the START point "START" of the workflow in the figure), the execution condition is satisfied, which may be used as a trigger condition for the node device to generate a task allocation event corresponding to the task node a. For example, when the first transaction invokes the aforementioned transit method of a contract, the provided parameter ev may be

{

Type = "task _ a _ input",// event type

Args = args _ of _ task _ a,// method invocation parameter

}

Alternatively, the execution condition of the first task node may be: the entry parameter provided by the first transaction is the execution result of a second contract task corresponding to a second task node in the workflow, wherein the second task node is positioned before the first task node. For example, in the case that the first task node is the task node B1 corresponding to the contract task B1, the execution result of the contract task a may be used as the entry of the contract task B1, so that in the case that the entry provided by the first transaction is the execution result of the contract task a (i.e., indicating that the contract task a has been executed at the current time), the corresponding block link point instance may determine that the entry provided by the first transaction satisfies the execution condition. It can be seen that if the processing progress of the workflow at the current time is before the task node B1 (e.g., at the output position of the contracted task a in the figure), the execution condition is satisfied as a trigger condition for the node device to generate a task allocation event corresponding to the task node B1. Of course, the execution condition of the first task node may also include both of the above two types, that is, the execution condition may be "the entry provided by the first transaction is the execution result of the second contract task corresponding to the second task node located before the first task node in the workflow, and the data format of the execution result meets the requirement", thereby implementing more severe management on the entry of any task in the workflow.

Further, in the case that the first transaction is used to invoke a different method, the entries provided by the first transaction may also have a different form. For example, the first transaction may invoke a method in the smart contract for advancing the workflow, in which case the entry provided by the first transaction may be independent of the second task node. As shown in fig. 6, assuming that the execution process of the contract task C does not require the execution result of the contract task B1 and/or the contract task B2, in the case that the first task node is the task node C, the first transaction is only used to advance the workflow from the contract task B1 to the contract task C in sequence, so that only the parameter related to the execution of the contract task C needs to be provided, so the parameter may be unrelated to the contract task B1 and/or the contract task B2 (in this case, the task node B1 and/or the task node B2 is the second task node).

For another example, after executing any task, the node device may return the execution result of the task of the second contract to the first task node by using a task callback method in the intelligent contract. When the first transaction calls the task callback method in the intelligent contract, the fact that the input parameter provided by the first transaction is the execution result of the second contract task is indicated; wherein the method for advancing the workflow can be automatically triggered after the task callback method is called. The callback process may be seen by dashed line a2 for contract task A and dashed line C2 for contract task C in FIG. 6. For example, the intelligent contract may feed back the execution result of the first contract task to the first task node by using a callback method corresponding to the transit method described above. The intelligent contract can provide the following callback method:

void callback(TaskId task_id, Bytes result) {

transit({

.type = “task_” + task_id + “result”,

.args = result,

});

}

in one embodiment, the execution condition of the first task node may include a plurality of execution sub-conditions, such that in a case where the entry provided by the first transaction satisfies all of the execution sub-conditions of the first task node, or satisfies a part of the execution sub-conditions of the first task node and the remaining execution sub-conditions have been satisfied by the entry provided by the second transaction recorded by the block-linked point instance, the block-linked point instance may determine that the execution condition of the first task node is satisfied; in the case that the entry provided by the first transaction satisfies the partial execution sub-condition of the first task node and there is an execution sub-condition that has not been satisfied, the block link node instance may record the entry provided by the first transaction and wait.

Still taking the example shown in fig. 6 as an example, it is not assumed that the execution of the contract task C described above requires the execution results of the contract task B1 and the contract task B2 at the same time, that is, the execution conditions of the task node C include "acquisition of the execution result of the contract task B1" and "acquisition of the execution result of the contract task B2". In the case where the respective contract tasks in the workflow are executed according to the dependency relationship therebetween, the contract task B1 and the contract task B2 may be executed by a method called by the first transaction at the same time, so that the argument provided by the first transaction may include the execution results of the contract task B1 and the contract task B2, and the corresponding block link point instance may determine that the execution condition of the first task node is satisfied, thereby executing the contract task C in quick response to the first transaction. Alternatively, each contract task in the workflow may be executed in response to a method called by a different transaction, respectively, so that a first transaction may be used to provide the execution result of the contract task B1, and a second transaction different from the first transaction may be used to provide the execution result of the contract task B2 before the execution of the first transaction is finished, and then in the case where the execution result of the contract task B2 provided by the second transaction has been obtained, the block link point instance may determine that the execution condition of the first task node is satisfied if the execution result of the contract task B1 provided by the first transaction is further received. Accordingly, in the case where the execution result of the contract task B1 provided for the first transaction is obtained, if the execution result of the contract task B2 provided for the second transaction is not obtained yet, the block link point instance may determine that the execution condition of the first task node has not been satisfied yet, and may wait for the execution result of the contract task B2 provided for the second transaction until it is determined that the execution condition of the first task node is satisfied when the result is obtained. By the method, the task allocation event corresponding to the first task node is generated only when each execution sub-condition in the execution conditions of the first task node is met.

In step 504, the service instance executes a first contract task if the task allocation event is monitored and the first contract task included in the task allocation event is determined to be allocated to a first blockchain member to which the first node device belongs.

For an intelligent contract deployed in a blockchain network, block chain link point instances of each block chain node in the blockchain network can generate the task allocation event, after the service instances of each block chain node respectively monitor the task allocation event, whether a first contract task contained in the task allocation event is allocated to a first blockchain member to which first node equipment belongs is judged, and the first contract task is executed under the condition that the first contract task is determined to be allocated to the first blockchain member. The first contract task may be generated and issued by using the aforementioned event mechanism, such as the dashed line a1 corresponding to the contract task a and the dashed line C1 corresponding to the contract task C in fig. 6. In the process corresponding to the dotted line a1, the task scheduling framework in the node device 1 is configured to monitor a task allocation event corresponding to the intelligent contract; in the process corresponding to the dotted line c1, the task scheduling framework in the node device 2 is configured to monitor a task allocation event corresponding to the intelligent contract, and after monitoring any task allocation event, any task scheduling framework determines a computing unit for executing a corresponding contract task according to a task requirement or a data requirement specified by the event, and schedules the computing unit to sequentially complete a related computing process for the contract task, thereby completing the execution process for the contract task, and the specific process is not described again.

As shown in fig. 6, for the intelligent contracts deployed in the blockchain network, it is not assumed that the contract task a is assigned to the blockchain member 1 of the node device 1, and the contract task C is assigned to the blockchain member 2 of the node device 2 (the execution processes of the contract task B1 and the contract task B2 are not shown and will not be described in detail). The service instance deployed in any node device may include a task scheduling framework, a task unit container and task units managed by the task unit container, wherein the task scheduling framework is connected with at least one task unit container for managing the task units and is used for realizing task distribution of contract tasks and computing resource scheduling in the task execution process; the task unit is used for executing a specific contract task; while the block link point examples deployed in node device 1 and node device 2 are not shown.

In one embodiment, the blockchain link point instance may include the identity information of the blockchain member of the assignment object in the task assignment event, so that the service instance may determine that the first contract task included in the task assignment event is assigned to the first blockchain member to which the first node device belongs, that is, determine that the first contract task is executed by the service instance, in the case that the identity information of the first blockchain member is included in the task assignment event. The identity information may be a member identifier of a blockchain member, an equipment identifier of a node device (in a case where only one blockchain node in the blockchain network is deployed in one node device), a node public key of a blockchain node corresponding to the blockchain member, or an abstract of the node public key, and the like, which is not limited in this specification. Alternatively, the corresponding task allocation condition may be specified in advance for the blockchain member, so that the service instance may determine that the first contract task included in the task allocation event is allocated to the first blockchain member to which the first node device belongs, that is, determine that the service instance executes the first contract task, when the task content of the first contract task matches the task allocation condition corresponding to the first blockchain member.

Further, in a case where the service instance in any node device determines that it executes the first contract task, the service instance may execute the first contract task according to the entries carried in the task allocation event. In addition, under the condition that the processing progress of the workflow at the current moment is before the first task node and the access provided by the first transaction enables the execution condition of the first task node to be met, the block link point instance can update the processing progress of the workflow to be behind the first task node, so that the state transition of the workflow state corresponding to the intelligent contract is promoted. Corresponding to the workflow and task execution process of FIG. 6, the workflow states may be defined in the intelligent contracts as follows:

enum class WorkflowState {

waiting_task_a_input,

waiting_task_a_result,

waiting_task_b1_and_b2_result,

waiting_task_b1_result,

waiting_task_b2_result,

waiting_task_c_result,

}

accordingly, the state transition diagram of the smart contract can be seen in FIG. 7. As shown in fig. 7, the intelligent contract is executed at the START point START of the workflow, the workflow status of the intelligent contract is "input of waiting task a" first, and in the case that the first transaction provides the entry of contract task a and the entry satisfies the execution condition of contract task a, the service instance in the node device STARTs executing contract task a, and the corresponding workflow status is updated to "output of waiting task a". After the contract task A is completed and the execution result is obtained, the contract task B1 and the contract task B2 are started to be executed by the service instance in the corresponding node device, and the workflow state is correspondingly updated to be the result of the waiting tasks B1 and B2. Because the execution speed or the execution sequence of the contract task B1 and the contract task B2 is uncertain, the contract task B2 may be executed first and obtain the execution result, so that the workflow status is updated to the result of the "waiting task B1", and further, after the execution of the contract task B1 is finished and the execution result is obtained, the contract task C may be executed, and the workflow status is updated to the result of the "waiting task C"; it is also possible that the contract task B1 is executed first and gets the execution result, so that the workflow status is updated to "the result of waiting for task B2", and then after the contract task B2 is executed and gets the execution result, the contract task C is started to be executed, and the workflow status is updated to "the result of waiting for task C". And finally, after the execution of the contract task C is finished and an execution result is obtained, all the contract tasks in the workflow are finished, namely the intelligent contract is finished to the END point END of the workflow.

In an embodiment, the first contract task may be in the form of various tasks such as privacy computation, file system access, database access, and the like, and the service instance may also execute the first contract task in various ways. For example, the service instance may invoke a computing resource deployed locally at the node device to perform a first contract task, e.g., the service instance in the node device 1 may invoke a task unit managed by the task unit container 11 deployed locally at the node device 1 to perform a contract task a (in this case, the contract task a is the first contract task). For another example, the service instance may invoke a computing resource deployed outside the node device to execute the first contract task, for example, the service instance in the node device 2 may invoke a task unit managed by the task unit container 21 deployed locally in the node device 2 to cooperate with an off-link computing resource deployed in another device outside the node device 2 to execute the contract task C (in this case, the contract task C is the first contract task). Of course, the service instance in the node device 1 may also invoke a plurality of computing resources deployed locally on the node device to execute the contract task a at the same time, or the service instance in the node device 2 may also invoke only the out-of-link computing resource to execute the contract task C, which is not limited in this specification. In the scheme practice, appropriate computing resources can be flexibly selected to execute the first contract task according to actual task requirements such as task types, computing resource consumption, time consumption requirements and the like, so that more flexible scheme practice is realized, and the application scenes of the method in the specification are expanded.

In one embodiment, a service instance may feed back a corresponding execution result to an intelligent contract after executing a first contract task, so that the intelligent contract executes a subsequent task based on the execution result. For example, after the service instance in the node device 1 executes the contract task a, the execution result of the contract task a may be fed back to the intelligent contract; after the service instance in the node device 2 executes the contract task C, the execution result of the contract task C may also be fed back to the intelligent contract. Of course, the service instances corresponding to the contract task B1 and the contract task B2 may also be fed back to the intelligent contract after the execution obtains the corresponding execution result. In addition, in order to reduce the data transmission amount and reduce the network pressure of the block chain network, after the intelligent contract is executed, only the final execution result of the intelligent contract may be returned to the intelligent contract, which is not described again.

Further, the task assignment event may include both a first contract task assigned to a first blockchain member to which the first node device belongs and a second contract task assigned to a second blockchain member to which the second node device belongs, such that the first contract task is executed by the service instance in the first node device and the second contract task is executed by the service instance in the second node device. Correspondingly, the service instance executing the first contract task can acquire the execution result of the second contract task (from the service instance executing the second contract task) and feed the execution result back to the intelligent contract, so that one-time feedback of a plurality of execution results is realized, the calling times of the intelligent contract callback method are reduced, and the execution efficiency of the intelligent contract is further improved.

In another embodiment, the task allocation event may further include a contract task allocated to a member of the blockchain to which at least one other node device different from the first node device belongs, and at this time, the service instance may send an execution result of the first contract task to a master node device determined from the at least one other node device, so that the master node device feeds the execution result back to the intelligent contract. The example is still described with the task assignment event including both a first contract task assigned to a first blockchain member to which a first node device belongs and a second contract task assigned to a second blockchain member to which a second node device belongs.

As shown in fig. 6, assuming that the first contract task (i.e., contract task a) includes a first subtask a1 and a second subtask a2, and the first subtask a1 corresponding to the task node 1 is assigned to the first blockchain member to which the first node device belongs, and the second subtask a2 is assigned to the second blockchain member to which the second node device belongs, the service instance in the node device 1 and the service instance in the node device 2 may respectively execute the first subtask a1 and the second subtask a 2. In addition, the task allocation event may also specify any node device of the node device 1 and the node device 2 as a master node device, or the master node device may also be determined by self-negotiation between the node device 1 and the node device 2. Therefore, after the service instance in the node device 2 finishes executing the second subtask a2, the execution result may be sent to the master node device. Accordingly, after the service instance in the node device 1 finishes executing the first sub-task a1, it may be checked whether the execution result of executing the second sub-task a2 sent by the service instance in the node device 2 has been received: if the execution result is received, the service instance in the node device 1 may feed back both execution results to the intelligent contract; if the execution result is not received, the service instance in the node device 2 may wait for the execution of the second subtask a2 to be completed, and after receiving the corresponding execution result, feed back the result and the execution result of the first subtask a1 to the intelligent contract. By the method, under the condition that the task allocation event comprises a plurality of contract tasks, all execution results can be fed back to the intelligent contract by only one node device, multiple times of feedback of the task execution results is effectively reduced, and the contract execution efficiency is improved to a certain extent.

In the above embodiments, the blockchain network is taken as an example of the blockchain master network subnet0 shown in fig. 4, and actually, the task execution method based on the intelligent contract described in this specification may be applied to any blockchain network described in fig. 4: whether it is a blockchain master network or a blockchain sub-network. In the case of being applied to a blockchain subnet (that is, the blockchain node instance belongs to a blockchain subnet managed by a blockchain master network), the service instance may also submit the execution result of the first contract task to the blockchain master network to store the execution result in the blockchain master network, so that the execution result of the first contract task is guaranteed to be difficult to be tampered by the blockchain master network with a larger scale, and reliable storage of the execution result is achieved.

For example, in the case that the above method is applied to subnet1 (i.e., a blockchain subnet) shown in fig. 4, after executing contract task a (i.e., the first contract task) and obtaining the corresponding execution result, the service instance in node device 1 may submit the execution result to subnet1 (i.e., a blockchain main network), so as to store the execution result in subnet 1. Of course, various different submission manners may be adopted, such as submitting a complete execution result (content storage certificate), submitting an abstract of the execution result (hah storage certificate), submitting an encrypted execution result (privacy storage certificate), and the like, and details are not repeated.

FIG. 8 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 8, at the hardware level, the apparatus includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, but may also include hardware required for other services. The processor 802 reads a corresponding computer program from the nonvolatile memory 810 into the memory 808 and then runs the computer program to form a task execution device based on the intelligent contract on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 9, in an embodiment, the intelligent contract-based task execution apparatus is applied to a first node device deployed with a block link point instance and a service instance, and the apparatus may include:

an event generating unit 901, which enables the block link point instance to respond to a first transaction calling a workflow defined in an intelligent contract, and generates a task allocation event corresponding to a first task node if the processing progress of the workflow is before the first task node and an entry provided by the first transaction enables an execution condition of the first task node to be satisfied;

the task execution unit 902 causes the service instance to execute the first contract task if the task distribution event is monitored and the first contract task contained in the task distribution event is determined to be distributed to the first blockchain member to which the first node device belongs.

Optionally, the execution condition includes at least one of:

the data format of the input parameter provided by the first transaction meets the requirement;

and the entry parameter provided by the first transaction is the execution result of a second contract task corresponding to a second task node which is positioned in front of the first task node in the workflow.

Alternatively to this, the first and second parts may,

when the first transaction calls a device used for promoting the workflow in the intelligent contract, indicating that the entry is irrelevant to participate in a second task node;

when the first transaction calls the task callback device in the intelligent contract, the participation is indicated as the execution result of the second contract task; wherein the task callback device automatically triggers the means for advancing the workflow after being invoked.

Optionally, the execution condition of the first task node includes a plurality of execution sub-conditions, and the apparatus further includes:

a condition determining unit 903, configured to enable the block chain node instance determination execution condition to be satisfied when the entry provided by the first transaction satisfies all execution sub-conditions of the first task node, or satisfies part of the execution sub-conditions of the first task node, and the remaining execution sub-conditions are satisfied by the entry provided by the second transaction recorded by the block chain node instance;

the parameter recording unit 904, in a case that the entry provided by the first transaction satisfies the partial execution sub-condition of the first task node and there is an execution sub-condition that is not yet satisfied, causes the block link point instance to record the entry provided by the first transaction and wait.

Optionally, determining that a first contract task included in the task assignment event is assigned to a first blockchain member to which a first node device belongs is performed in any of the following cases:

the task distribution event comprises identity information of the first blockchain member;

the task content of the first contract task matches the task distribution condition corresponding to the first blockchain member.

Optionally, the method further includes:

the node updating unit 905 is configured to, when the processing progress of the workflow is before the first task node and the entry provided by the first transaction satisfies the execution condition of the first task node, cause the block chain node instance to update the processing progress of the workflow to be after the first task node.

Optionally, the task execution unit 902 is further configured to:

causing the service instance to invoke a computing resource deployed locally to the node device to perform the first contracted task; and/or the presence of a gas in the gas,

causing the service instance to invoke the computing resource deployed outside of the node device to perform the first contracted task.

Optionally, the method further includes:

and a self-feedback unit 906, which enables the service instance to feed back the execution result of the first contract task to the intelligent contract.

Optionally, the method further includes:

the first centralized feedback unit 907, in the case that the task allocation event further includes a second contract task allocated to a second blockchain member to which a second node device belongs, causes the service instance to obtain an execution result of the second contract task, and feeds the execution result back to the intelligent contract.

Optionally, the method further includes:

the second centralized feedback unit 908, in a case where the task allocation event further includes a contract task allocated to a blockchain member to which at least one other node device different from the first node device belongs, causes the service instance to send an execution result of the first contract task to a master node device determined from the at least one other node device, so that the master node device feeds the execution result back to the intelligent contract.

Optionally, the block chain node instance belongs to a block chain sub-network, and the block chain sub-network is managed by a block chain main network; the device further comprises:

a result storing unit 909, which causes the service instance to submit the execution result of the first contract task to the blockchain master network, so as to store the execution result in the blockchain master network.

Optionally, the block link point instance and the service instance are in different processes.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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.

This description 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. The 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.

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 a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

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 computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that 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, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A task execution method based on an intelligent contract is applied to first node equipment deployed with block link point instances and service instances, and comprises the following steps:

in the process of executing the intelligent contract in response to a first transaction for invoking a workflow defined in an intelligent contract, if the processing progress of the workflow is before a first task node and the access provided by the first transaction enables the execution condition of the first task node to be met, generating a task allocation event corresponding to the first task node by the block link point instance;

the service instance executes a first contract task under the conditions that the task distribution event is monitored and the first contract task contained in the task distribution event is distributed to a first blockchain member to which a first node device belongs;

and in the case that the task allocation event further includes a contract task allocated to a blockchain member to which at least one other node device different from the first node device belongs, the service instance sends an execution result of the first contract task to a master node device determined from the at least one other node device, so that the master node device feeds the execution result back to the intelligent contract.

2. The method of claim 1, the execution condition comprising at least one of:

3. The method of claim 2, wherein the first and second light sources are selected from the group consisting of,

when the first transaction calls a method for promoting the workflow in the intelligent contract, indicating that the entry is irrelevant to participate in a second task node;

when the first transaction calls a task callback method in the intelligent contract, the participation is indicated as an execution result of a second contract task; wherein the method for advancing the workflow is automatically triggered after the task callback method is called.

4. The method of claim 1, the execution condition of the first task node comprising a plurality of execution sub-conditions, the method further comprising:

in the case that the entry provided by the first transaction satisfies all of the execution sub-conditions of the first task node, or satisfies some of the execution sub-conditions of the first task node and the remaining execution sub-conditions have been satisfied by the entry provided by the second transaction recorded by the blockchain node instance, the blockchain node instance determines that the execution condition is satisfied;

in the case that the entry provided by the first transaction satisfies the partial execution sub-condition of the first task node and there is an execution sub-condition that has not been satisfied, the block link point instance records the entry provided by the first transaction and waits.

5. The method of claim 1, determining that a first contracted task included in the task allocation event is allocated to a first blockchain member to which a first node device belongs, if any of:

6. The method of claim 1, further comprising:

and in the case that the processing progress of the workflow is before the first task node and the participation provided by the first transaction enables the execution condition of the first task node to be met, the block chain node instance updates the processing progress of the workflow to be after the first task node.

7. The method of claim 1, the service instance performing the first contract task, comprising:

the service instance calls a computing resource locally deployed in the node equipment to execute the first contract task; and/or the presence of a gas in the gas,

the service instance invokes a computing resource deployed outside of the node device to perform the first contracted task.

8. The method of claim 1, further comprising:

and the service instance feeds back the execution result of the first contract task to the intelligent contract.

9. The method of claim 8, further comprising:

and under the condition that the task distribution event also comprises a second contract task distributed to a second blockchain member to which a second node device belongs, the service instance acquires an execution result of the second contract task and feeds the execution result back to the intelligent contract.

10. The method of claim 1, the blockchain link point instance belonging to a blockchain subnet managed by a blockchain master network; the method further comprises the following steps:

and the service instance submits the execution result of the first contract task to the block chain main network so as to store the execution result in the block chain main network.

11. The method of claim 1, the block-link node instance and a service instance are in different processes.

12. A task execution device based on an intelligent contract is applied to first node equipment deployed with block link point instances and service instances, and the device comprises:

the event generating unit enables the block link point instance to generate a task allocation event corresponding to a first task node if the processing progress of the workflow is before the first task node and the input participation provided by the first transaction enables the execution condition of the first task node to be met in the process of responding to the first transaction of the workflow defined in the intelligent contract to execute the intelligent contract;

the task execution unit is used for enabling the business instance to execute a first contract task under the condition that the task distribution event is monitored and the first contract task contained in the task distribution event is determined to be distributed to a first blockchain member to which the first node equipment belongs;

and a centralized feedback unit, configured to, when the task allocation event further includes a contract task allocated to a blockchain member to which at least one other node device different from the first node device belongs, cause the service instance to send an execution result of the first contract task to a master node device determined from the at least one other node device, so that the master node device feeds back the execution result to the intelligent contract.

13. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-11 by executing the executable instructions.

14. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 11.