CN113067898B

CN113067898B - Method for scheduling computing services for business process contracts

Info

Publication number: CN113067898B
Application number: CN202110611549.4A
Authority: CN
Inventors: 邓福喜; 谢桂鲁; 赵博然
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2021-08-10
Anticipated expiration: 2041-06-02
Also published as: WO2022252996A1; CN113067898A

Abstract

The invention provides a method for scheduling computing service for business process contracts. And running a scheduling process independent of the nodes on the node equipment corresponding to at least part of the nodes, wherein the scheduling process is used for scheduling the computing service process independent of the nodes running on the node equipment. And for each computing task in the business process contract, scheduling a computing service process which can be occupied on the same node equipment and corresponds to the computing type as a computing service process serving the computing task according to the computing type of the computing task. In this way, the blockchain network may invoke the computing service process occupied by each computing task through the scheduling process to execute the computing task in the process of executing the business process contract.

Description

Method for scheduling computing services for business process contracts

Technical Field

One or more embodiments of the present disclosure relate to the field of terminal technologies, and in particular, to a method for scheduling computing services for business process contracts.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data.

In practical applications, business process contracts (intelligent contracts for realizing specific business processes) are sometimes required to be deployed in the blockchain network, however, all calculations involved in the business process contracts are executed by nodes of the blockchain network, and the pushing efficiency of the business processes has strong dependency on the operation states of the nodes.

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a method for scheduling computing services for business process contracts.

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, there is provided a method for scheduling computing services for a business process contract, where a business process contract is deployed on a blockchain network, the business process contract defining each computing task for implementing a business process and specifying at least one node participating in each computing task; the method is applied to a scheduling process which is also operated on node equipment corresponding to each node, and comprises the following steps:

aiming at least part of the computing tasks defined in the business process contract, under the condition that the corresponding node participates in the computing task, according to the computing type of the computing task, a computing service process which corresponds to the computing type and is in an occupiable state and is still operated on the corresponding node equipment is scheduled to be a computing service process occupied by the computing task;

and the block chain network calls a computing service process occupied by each computing task through a scheduling process to execute the computing task in the process of executing the business process contract.

According to a second aspect of one or more embodiments herein, there is provided an apparatus for scheduling computing services for a business process contract, the business process contract being deployed on a blockchain network, the business process contract defining each computing task for implementing a business process and specifying at least one node participating in each computing task; the method is applied to a scheduling process which is also operated on node equipment corresponding to each node, and the device comprises the following steps:

a scheduling module, configured to schedule, for at least part of the computation tasks defined in the service flow contract, a computation service process that is still running on the corresponding node device and is in an occupiable state and corresponds to the computation type of the computation task as a computation service process occupied by the computation task according to the computation type of the computation task when it is determined that the corresponding node participates in the computation task;

According to a third aspect of one or more embodiments of the present specification, a blockchain network is provided, on which a business process contract is deployed, the business process contract defining therein each computing task for implementing a business process and specifying at least one node participating in each computing task;

a node-independent scheduling process which is also operated on the node equipment corresponding to each node, and which is used for scheduling a computing service process which is also operated on the corresponding node equipment, corresponds to the computing type and is in an occupiable state into a computing service process occupied by the computing task according to the computing type of the computing task under the condition that at least part of the computing task defined in the business process contract is determined to be participated in the computing task;

In one or more embodiments of the present disclosure, a node device corresponding to at least some nodes runs a node-independent scheduling process, and the scheduling process is configured to schedule a node-independent computing service process running on the node device. And for each computing task in the business process contract, scheduling a computing service process which can be occupied on the same node equipment and corresponds to the computing type as a computing service process serving the computing task according to the computing type of the computing task. In this way, the blockchain network may invoke the computing service process occupied by each computing task through the scheduling process to execute the computing task in the process of executing the business process contract.

Based on the technical scheme, in the process of executing the business process contract by the node, each calculation task does not need to be directly executed, but at least part of the calculation tasks are directly executed by a calculation service process independent of the node, so that the dependence of the propelling efficiency of the business process on the running state of the node is weakened, and the propelling of the business process is not easily delayed even if the node runs abnormally. In addition, even if a certain computing task is abnormally executed, the abnormal repair of the node is not needed, and the running state of the node is not easily influenced.

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 flowchart of a method for building a blockchain subnet according to an exemplary embodiment.

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

Fig. 6 is a flowchart of another method for building a blockchain subnet provided by an example embodiment.

FIG. 7 is a flow diagram of a method for scheduling computing services for a business process contract.

FIG. 8 is a flow diagram of a method for business execution based on an out-of-chain computing service.

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 realize message passing through an event in a receipt so as to trigger the blockchain node or a node device deploying 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 blockchain node or the node device deploying the blockchain node may perform the preset processing by monitoring the topic of the event, in case that the predefined topic is monitored, or read the related content from the data field of the corresponding event, and may perform the preset processing 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.

A hardware-level blockchain network is generally composed of a plurality of member node devices. The node equipment of each member is provided with nodes, and the nodes arranged on the node equipment of each member form a software-level block chain network.

It is to be understood that different members are different individuals or entities and actually correspond to different interested parties. There may be multiple node devices (i.e., device clusters) for a member, and the member may flexibly (e.g., considering the performance of a single device) deploy in the device cluster several nodes belonging to different blockchain networks through which transactions in the different blockchain networks are engaged.

A node is a concept of a software layer, and one node can be understood as one instance (one process or one thread) of code for realizing the functions of the node, so that a plurality of instances for realizing the functions of the node can be deployed on a node device corresponding to the same member. In the case of a federated link network, the controller of a node is a federation member (enterprise) and the controller of a client is a user to which the enterprise interfaces, so that the multiple nodes can communicate with the client through different ports (or the same default port) of the node device to receive transactions submitted by the client.

In the case of a public link network, the node is included in the client, and the controller of the node is the controller of the client, i.e., the user.

Herein, for convenience of description, the "node receives a transaction submitted by a client" may refer to both the case of a federation chain network and the case of a public chain network.

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 an existing alliance chain network as an example, nodes of the alliance chain network are deployed on node devices of all alliance members (i.e., node members in an alliance), a blockchain network can be formed, that is, all alliance members respectively have corresponding blockchain nodes in the blockchain network, and all transactions and related data occurring on the blockchain network can be obtained through the corresponding blockchain nodes. In some cases, however, there may be some federations who wish to perform some transactions with privacy requirements within a small range, and who wish to be able to both verify such transactions on the blockchain or to take advantage of other advantages of blockchain technology, and to avoid other federations viewing such transactions and associated data.

To this end, the embodiments of the present specification provide a blockchain system participated by a plurality of members, the system includes, on a hardware level, a node device of each member, at least one node is deployed on the node device of each member, and different nodes deployed on the node device of the same member belong to different blockchain networks. Meanwhile, the system has a tree structure in a software layer, wherein the tree structure takes the block chain main network as a root node and each block chain sub network as other nodes.

It should be noted that the nodes and nodes described herein are different concepts. A node is a concept in the sense of a blockchain, and refers to a node in a blockchain network; and a node is a concept in a tree structure, and refers herein to a blockchain network in the tree structure.

The blockchain master network can be regarded as the blockchain network at the uppermost level in the system, and generally consists of master network nodes deployed on node devices of all members of the system. It should be noted that in some embodiments, a member may be assigned a score of an initial member (a member participating in initializing the system) and a subsequent member (a member joining after system initialization). All initial members construct a blockchain system, a blockchain main network in the system is composed of main network nodes deployed on node devices of all initial members, and then more subsequent members can join the blockchain system, and main network nodes can be deployed on the node devices of the subsequent members so as to join the main network, or only one or more sub-network nodes can be deployed without deploying the main network nodes.

The blockchain subnet in the system may have multiple levels. The block chain sub-network at the top level is a sub-node of the block chain main network in the tree structure. The blockchain sub-network can also have sub-nodes of the next-level blockchain sub-network. It should be noted that, in general, a master network node of a block chain master network is also deployed on a node device corresponding to a node of a block chain sub-network. In the embodiment where there is a difference between the initial member and the subsequent member in the system, the node device corresponding to the node of one blockchain subnet may be the node device of the subsequent member, and the node device of the subsequent member may not deploy the main network node.

By means of the blockchain system, individual members can self-establish a blockchain sub-network to conduct small-range transactions, and the blockchain networks (whether main networks or sub-networks) in the system are mutually isolated in data.

In some embodiments, the blockchain network may be created by manually deploying on its own node device by each member, and if 3 nodes of different blockchain networks (one main network and two subnets) need to be deployed on the node device of one member, the member needs to perform a process of manually deploying the blockchain network on the node device three times. However, for the member, each time a node of a new blockchain network needs to be additionally deployed on its own node device, the member needs to perform the manual deployment procedure again, which is troublesome. Moreover, the small-scale transaction requirements among some members are often temporary or have certain timeliness, so that the manually deployed new blockchain subnet can lose significance quickly due to the disappearance of the requirements, and the cancellation of the blockchain subnet requires the members to manually operate the node equipment, which further increases the trouble.

To this end, in some embodiments, another method of creating a blockchain network in a system is presented. And taking the block chain main network initially established in the system as a base, and establishing a block chain sub-network on the basis of the block chain main network.

Specifically, a blockchain main network accepts a subnet creation transaction, processes the subnet creation transaction based on a deployed contract, triggers a subnet creation event, and creates an instance as a node of a created subnet according to configuration information carried by the subnet creation transaction if each main network node determines that a member of a node device corresponding to the main network node participates in the subnet after monitoring the subnet creation event. Each blockchain subnet can also further accept subnet creation transactions and process the subnet creation transactions based on deployed contracts, and trigger subnet creation events, after each subnet node in the blockchain subnet monitors the subnet creation events from the subnet node, if it is determined that members of the node device corresponding to the blockchain subnet node participate in the next-level subnet, an instance is created according to configuration information carried by the subnet creation transactions, and the instance is used as a node of the further-created next-level subnet.

In this context, for any blockchain subnet, if the blockchain network responsible for processing the subnet creation transaction used to create the blockchain subnet, i.e., the blockchain network referred to as creating the blockchain subnet, is the parent node of the blockchain subnet in the tree structure. In the tree structure, the blockchain subnet of the child node of the parent node is not necessarily created by the parent node, but may still be managed by the parent node (i.e., the network identifier and address information of the blockchain subnet of the child node are recorded in the blockchain network of the parent node).

In these embodiments, any blockchain subnet is created and managed by the blockchain network corresponding to its parent node. In this way, the member usually only needs to complete one manual deployment of the master network node on its own node device, and the master network node on the node devices of the subsequent members can create a new instance as the next-level sub-network node. The node of a block chain sub-network on the node devices of some members can further create a new instance as a sub-network node of a lower level. Through the hierarchical network deployment mode, the trouble of manual deployment of members can be reduced.

In addition, in these embodiments, node devices of some subsequent members may still be added to the system after the blockchain sub-network is deployed, which means that the blockchain sub-network is not created by any original blockchain network in the system, but is directly added to the blockchain sub-network in the system from the outside, and such blockchain sub-network may still be added to the tree structure to become a node, except that the blockchain sub-network of the node is managed (not created) by the blockchain network corresponding to its parent node.

Through the above subnet creating and managing manner, any blockchain subnet is either created and managed by the blockchain network of the parent node, or is directly added into the tree structure from the outside and managed by the blockchain network of the parent node. In either case, the address information of any blockchain subnet (i.e. the address information of each node contained therein, such as IP address and port number) can be exposed only to the blockchain network of its parent node, and recorded by each node in the blockchain network of its parent node. Therefore, the privacy of the subnet can be ensured to the maximum extent, and the risk of network attack is reduced.

The building scheme of the block chain sub-network in this specification is described below with reference to fig. 4. It should be noted that, the node member in the following description specifically refers to a member; the node equipment refers to equipment controlled by members and is a concept of a hardware level; a node refers to a node instance (a process or a thread running on a node device), is deployed on the node device, and is a concept of a software layer.

Referring to fig. 4, fig. 4 is a flowchart of a method for building a blockchain subnet according to an exemplary embodiment. As shown in fig. 4, the method may include the steps of:

step 402, each block link point in a block link main network respectively acquires a transaction for building a block link sub-network, wherein the transaction includes configuration information of the block link sub-network, and the configuration information includes identity information of node members participating in building the block link 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. 5, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Suppose that the node members respectively corresponding to nodeA, nodeB, nodeC and nodeD wish to construct 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, no matter an administrator or an ordinary user, the node members corresponding to the blockchain link points initiating the transaction for building the blockchain subnet do not necessarily participate in the built blockchain subnet, for example, although the blockchain subnet is finally built by the node members respectively corresponding to nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated to subnet0 by nodeE, 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 constructed on subnet0 shown in fig. 5, subnet0 may be considered to be at the first level and subnet1 may be considered to be at the second level. In one case, the blockchain main network in this specification may be an underlying blockchain network, that is, the blockchain main network is not a blockchain sub-network constructed on the basis of other blockchain networks, for example, the subnet0 in fig. 5 may be regarded as a blockchain main network belonging to the underlying blockchain network type. In another case, the blockchain master network in this specification may be a sub-network of another blockchain network, for example, another blockchain sub-network may be further configured on the basis of the subnet1 in fig. 5, and at this time, the subnet1 may be considered as the blockchain master network corresponding to the blockchain sub-network, and this does not affect that the subnet1 belongs to the blockchain sub-network created on the subnet0 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

In step 404, each block link node in the block chain master network performs the transaction to reveal the configuration information.

Step 406, when the configuration information includes identity information of a node member corresponding to the first block link point, the node device deploying the first block link node starts a second block link node belonging to the block link subnet based on the creation block including the configuration information.

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, the transaction is executed by each blockchain link point, so that the establishment of the blockchain sub-network is completed. 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 identity information of the node members participating in the building of the blockchain subnet in the configuration information, it can be specified to which node members the built blockchain subnet corresponds.

The identity information of the node member may include a public key, or other information capable of representing the identity of the node member, such as a node ID, which is not limited in this specification. Taking a public key as an example, each block chain node has one or more corresponding public and private key pairs, and the block chain node holds the private key and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding block chain node can be represented by the public key, and the identity of a node member corresponding to the block chain node can also be represented by the public key. Therefore, for the node members who wish to participate in building the blockchain sub-network, the public keys of the blockchain nodes corresponding to the node members on the blockchain main network can be added to the transaction of building the blockchain sub-network to serve as the identity information of the node members. The public and private key pair described above may be used in the process of signature verification. For example, in a signed consensus algorithm, such as the sub net1, the above-mentioned nodeA1 signs a message with its own private key, and broadcasts the signed message in the sub net1, while nodeB1, nodeC1 and nodeD1 can verify that the received message is signed with the public key of nodeA1 to confirm that the received message is indeed from nodeA1 and has not been tampered with.

The first block link point may be a block link point on the block chain backbone corresponding to a node member indicated by the configuration information. When building the block chain sub-network, the first block chain link point does not directly participate in building the block chain sub-network, but the node device for deploying the first block chain node needs to generate a second block chain node, and the second block chain link point participates in building the block chain sub-network. The first block chain node and the second block chain node correspond to the same node member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first block chain node belongs to a block chain main network, and the second block chain node belongs to a block chain sub-network, so that the node member can participate in the transactions of the block chain main network and the block chain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the block generated by the first blockchain link point and the block generated by the second blockchain link point 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 blockchain link point and the second blockchain link point is realized, data generated by the blockchain sub-network can only be synchronized among the blockchain nodes in the blockchain sub-network, so that the node members only participating in the blockchain main network can not obtain the data generated on the blockchain sub-network, data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial node members (namely, the node members participating in the blockchain sub-network) are met.

The first blockchain node and the second blockchain node are logically divided blockchain link points, and from the perspective of physical devices, the node device which is equivalent to the first blockchain node and the second blockchain node is deployed to participate in both the blockchain main network and the blockchain sub-network. Since the identity systems of the two blockchain networks are independent from each other due to the independence between the blockchain main network and the blockchain sub-network, even though the first blockchain node and the second blockchain node may use the same public key, they should be regarded as different blockchain nodes. For example, in fig. 5, the nodeA in subnet0 corresponds to a first blockchain node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a second blockchain node. It can be seen that, because the identity systems are independent of each other, even if the public key adopted by the second blockchain node is different from the first blockchain node, the implementation of the scheme in this specification is not affected.

Of course, the node members participating in the blockchain sub-network are not necessarily only a part of the node members participating in the blockchain main network. In some cases, the node members participating in the blockchain subnet may be completely consistent with the node members participating in the blockchain main network, and at this time, all the node 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 block chain sub-network by the block chain main network is that since the first block chain node is already deployed on the node device generating the second block chain node, the block chain platform code used by the first block chain node can be multiplexed on the second block chain node, so that repeated deployment of the block chain platform code is avoided, and the building efficiency of the block chain sub-network is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the second blockchain link point may reuse the attribute configuration adopted on the first blockchain node; if the configuration information includes the attribute configuration for the blockchain platform code, the second blockchain link point may adopt the attribute configuration, so that the attribute configuration adopted by the second blockchain node is not limited to the attribute configuration of the first blockchain node and is independent of the first blockchain link point. 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, the nodeA-nodeE or the node devices 1-5 deploying the nodeA-nodeE can determine to monitor the event related to the execution of the AddSubnet () method, namely the networking event, by monitoring topic contained in each event in the generated receipt and under the condition of monitoring topic containing the keyword subnet. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

then, when the 1 st event is monitored, the event is determined to be irrelevant to the AddSubnet () method because the contained content of topic is other; and when the 2 nd event is monitored, determining that the event is related to an AddSubnet () method because the contained topic content is subnet, and further reading a data field corresponding to the event, wherein the data field contains 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, it may be determined whether the subnet1 already exists according to the recorded network identifications of all blockchain subnets that have been created; 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 participating in building the blockchain subnet. The node device deploying the first blockchain node may monitor the generated receipt, and acquire, by the node device deploying the first blockchain node, configuration information or a creation block included in the networking event when the networking event is monitored and the content of the networking event includes identity information of a node member corresponding to the first blockchain node. Or the first block link point may monitor the generated receipt, and trigger the node device deploying the first block link node to acquire the configuration information or the created block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first block link point belongs to the node member.

As previously described, the node device may listen for receipts directly. Assuming that nodeA to nodeE are respectively deployed on the node devices 1 to 5, and the node devices 1 to 5 can monitor receipts respectively generated by the nodeA to nodeE, the node devices 1 to 5 further identify the identity information of the node members included in the data field to determine their own processing modes when it is monitored that the subnet1 is a block chain subnet that needs to be newly built. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as a public key, an IP address, and a port number of nodeA, node device 1 generates a created block containing configuration information when obtaining the configuration information from the data field based on the above-mentioned message mechanism, and node device 1 deploys nodeA1 locally, and nodeA1 loads the generated created block, thereby becoming a subnet node of subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeB c1, and node device 4 may generate nodeB 1. And if the node device 5 finds that the identity information included in the data field does not match with itself, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in subnet 1.

As mentioned above, the blockchain link point in the blockchain master network can listen for the receipt and trigger the node device to perform the relevant processing according to the listening result. 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 generates a created block containing the configuration information when obtaining the configuration information from the data field based on the above message mechanism, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, thereby becoming a subnet node of the 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 block link point in the subnet 1.

As mentioned above, the first block link point and the second block link point do not necessarily use 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. Taking nodeA and node device 1 as an example: if identity information of nodeA1 is found in the data field, node device 1 may generate a founding block, deploy nodeA1, and load the founding block by nodeA 1; alternatively, nodeA, if identity information of nodeA1 is found in the data field, will trigger node device 1 to generate a foundational block, deploy nodeA1, and load the foundational block by nodeA 1. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

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 building a blockchain subnet, so that when a first blockchain node running the blockchain platform code executes a transaction, if the transaction is found to include the above networking transaction type identifier and the identity information of a node member corresponding to the first blockchain node is included in the configuration information in the transaction, a node device deploying the first blockchain node may be triggered to generate an innovation block including the configuration information and start a second blockchain node based on the processing logic, and the innovation block is loaded by the second blockchain node to form a blockchain node in the blockchain subnet.

The node equipment realizes the deployment of a blockchain node on the node equipment by creating an instance of a running blockchain platform code in a process. For the first blockchain node, it is formed by the node device creating a first instance of the running blockchain platform code in the above-described process. Similarly, for the second blockchain node, it is formed by the node device creating a second instance of the run blockchain platform code in the above-described process. For example, the node device may first create a first instance in a process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in building the blockchain subnet, a second instance may be created in the process, where the second instance is different from the first instance, and forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are located in the same process, the deployment difficulty of the second block chain node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved. Of course, the second instance may also be in a different process on the node device than the first instance, and this specification does not limit this; for example, the node device may create a first instance in a first process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in building the blockchain subnet, a second process different from the first process may be started, and a second instance different from the first instance may be created in the second process, so that the second blockchain node in the blockchain subnet is formed by the second instance.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 5 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, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeC2, nodeD and nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as new blockchain main networks, and a blockchain subnet is further constructed on the basis, which is similar to the construction of subnet1 or subnet2, and is not described herein again.

In the above embodiment as shown in fig. 4, the process of building a blockchain subnet in the present specification is actually described from the perspective of the whole blockchain system, and in this process, not all node members participate in the blockchain subnet, and next, in conjunction with fig. 6, the technical solution of the present specification will be described from the perspective of the master node participating in the blockchain subnet and the node device located in the master node. It will be readily appreciated that the embodiment shown in fig. 6 is not substantially different from the embodiment shown in fig. 4, and the foregoing description of the embodiment shown in fig. 4 applies to the embodiment shown in fig. 6.

Fig. 6 is a flowchart of another method for building a blockchain subnet provided by an example embodiment. As shown in fig. 6, the method may include the steps of:

step 602, a first blockchain link point in a blockchain master network obtains a transaction for building a blockchain subnet, where the transaction includes configuration information of the blockchain subnet, and the configuration information includes identity information of node members participating in building the blockchain subnet.

In step 604, the first block node performs the transaction to reveal the configuration information.

Step 606, when the configuration information includes identity information of a node member corresponding to the first block link point, the node device that deploys the first block link node starts a second block link node belonging to the block link subnet based on the creation block including the configuration information.

As previously described, the transactions that make up the blockchain subnet include transactions that invoke contracts.

As previously mentioned, the contracts include either a startup contract or a system contract.

As has been described in the foregoing, the present invention,

the execution result of the contract comprises the configuration information, the node equipment deploying the first block chain node obtains the configuration information through a message mechanism, and the created block is generated according to the obtained configuration information; or,

and the execution result of the contract comprises the creation block, and the node equipment for deploying the first block chain node obtains the creation block through a message mechanism.

As mentioned above, the receipt generated after the contract is executed contains networking events related to the establishment of a new blockchain subnet; the node device deploying the first block chain node obtains the configuration information or the creation block through a message mechanism, and the method includes:

monitoring a generated receipt by a first block chain link point, and triggering node equipment for deploying a first block chain node to acquire the configuration information or the created block contained in the networking event under the condition that the networking event is monitored and the content of the networking event indicates that the first block chain link point belongs to the node member; or,

and the node equipment deploying the first block chain node monitors the generated receipt, and acquires the configuration information or the created block contained in the networking event under the condition that the networking event is monitored and the content of the networking event indicates that the first block chain link point belongs to the node member.

As previously mentioned, the networking events include: the subject name in the receipt contains the event identified by the predefined networking event.

As mentioned above, when the content of the networking event contains the following identification, it indicates that the networking event is related to the establishment of a new blockchain subnet:

the network identification of the block chain sub-network which is expected to be established is different from the existing block chain sub-network; or,

and a predefined new network identifier, wherein the new network identifier indicates that the networking event is used for establishing a new block chain subnet.

As mentioned above, the transaction includes a networking transaction type identifier, which indicates that the transaction is used to construct a new blockchain subnet.

As has been described in the foregoing, the present invention,

the transaction of the building blockchain sub-network is initiated by an administrator of the blockchain main network; or,

and the transaction for establishing the blockchain sub-network is initiated by a common user of the blockchain main network.

As mentioned above, the configuration information further includes at least one of: the network identification of the blockchain subnet, the identity information of an administrator of the blockchain subnet, and the attribute configuration aiming at the blockchain platform code.

As previously described, the blockchain master network may be the same or different from the administrator of the blockchain sub-network.

As previously mentioned, the attribute configuration for blockchain platform code includes at least one of: code version number, whether consensus is required, consensus algorithm type, block size.

As previously described, the node device initiating a second block link point comprises: the node device creates a second instance of a run blockchain platform code distinct from the first instance of the first blockchain node on which the blockchain platform code is run.

As described above, the block generated by the first block link point and the block generated by the second block link point are stored in different storages on the node device.

As previously described, the storage used by the first block link point and the second block link point, respectively, are isolated from each other.

As previously mentioned, the storage is a database.

As described above, the block chain master network is a bottom layer block chain network; or, the block chain master network is a subnet of other block chain networks.

A method for scheduling computing services for a business process contract is provided herein. The method is usually implemented in a blockchain network, which may be a common blockchain network, or a main network or a sub-network in the blockchain system described above.

FIG. 7 is a flow diagram of a method for scheduling computing services for a business process contract, comprising the steps of:

step S700: and aiming at least part of the computing tasks defined in the business process contract, under the condition that the corresponding node participates in the computing task, according to the computing type of the computing task, scheduling a computing service process which is still running on the corresponding node equipment, corresponds to the computing type and is in an occupiable state as the computing service process occupied by the computing task.

The node device described herein may be a single device or a cluster of devices. The blockchain network described herein may be a public chain network or a alliance chain network.

A business process contract is deployed on the blockchain network, each computing task for realizing the business process is defined in the business process contract, and at least one node participating in each computing task is designated.

A business process contract is an intelligent contract used to implement a business process in a blockchain network. In the advancing process of the business process, several computing tasks are usually involved, and according to the actual situation, not all nodes are necessarily involved in a certain computing task, in other words, the nodes involved in each computing task may be all nodes of the blockchain network or may be partial nodes of the blockchain network.

In some embodiments, the computing tasks in a business process contract may be relatively independent of one another, i.e., the input to each computing task is not dependent on the output of other computing tasks.

In some embodiments, the computing tasks defined in the business process contract form a directed graph structure, and each node in the graph structure corresponds to each computing task one to one. For each calculation task, if the calculation task has an incoming edge, the calculation output of other calculation tasks connected with the incoming edge is the input of the calculation task; if the computing task is not bounded, the computing task does not need to be entered or input is specified by the transaction; if the computing task has an outgoing edge, the input of other computing tasks connected with the outgoing edge is the output of the computing task.

A node device corresponding to each node in the blockchain network generally runs a scheduling process independent of the node, and the scheduling process is used for scheduling a computing service process. The computing service process is a process for providing computing service for computing tasks, and the computing service process has computing capability and is independent of nodes. Generally speaking, computing function codes corresponding to different computing types are deployed on node devices corresponding to each node, and when a computing service process corresponding to a certain computing type needs to be created, a computing service process is created based on the computing function code corresponding to the computing type.

The scheduling process and the computing service process are processes outside the chain and do not depend on the running state of the node.

Generally, when nodes are deployed on node devices, a scheduling process is created together, and several computation-type computation function codes are deployed together on the node devices. It should be noted that, in practical applications, the types of computation of the computation function codes deployed on the node devices of different members of the blockchain network may be inconsistent, which may depend on the data sources that the different members can interface with and the computation capabilities of the different members. For example, for a federation chain network, a computing type of computing function code for computing credit risk may typically be deployed on a node device of a financial institution, while a computing type of computing function code for computing a logistics route may typically be deployed on a node device of a logistics institution.

Multiple compute service processes of the same compute type may be created on node devices of the same member. It should be noted that the functions of the computing service processes of the same computing type may not be completely the same. This is because, in practical applications, some computing service processes can provide general-purpose computing power, and such computing service processes can directly perform computing tasks related to general-purpose computing; however, some computing service processes may provide computing capability for a specific service scenario, which is equivalent to the combination of the service scenario and general computing capability, and the type division of the computing service processes is usually determined according to the general computing capability, so that it may happen that multiple computing service processes of the same computing type deployed on the same node device have different capabilities that are not completely consistent for different service scenarios. That is to say, different computing service processes corresponding to the same computing type are created by combining different service scenario configurations on the basis of the computing function code corresponding to the computing type, and are used for executing computing tasks in different service scenarios.

Generally, one or more business process contracts can be deployed in a blockchain network, and business scenarios targeted by different business process contracts are different, so that even if the same type of computing code is used, business scenario configurations specified in different business process contracts can be aggregated, and different computing service processes serving different business process contracts can be created.

For the creation opportunity of the computing service process, there are the following cases:

1. in some embodiments, before deploying the business process contract in the blockchain network, a number of computing service processes of computing types may be created (i.e., started) in advance based on the computing function codes of the computing types deployed on the node device corresponding to each node. In this way, after the block chain network deploys the business process contract, the scheduling process schedules the running computing service, and allocates the occupied computing service process for at least part of the computing tasks in the business process contract.

The term "occupation" as used herein refers to that a computing service process is dedicated to providing computing services for computing tasks, and after a computing service process is assumed to be occupied by a computing task, other computing tasks cannot occupy the computing service process, and an unoccupied computing service process is in an available state and can be regarded as being idle. In addition, it can also be set that N (more than 1) computing tasks can occupy the same computing service process, so that the computing service is in an available state as long as the number of computing tasks occupying the computing service process simultaneously does not reach N.

Of course, if many business process contracts are deployed in the network and a computing service process of a certain computing type is already occupied, when the computing service process of the computing type needs to be scheduled for a newly deployed business process contract, a new computing service of the computing type can be created temporarily.

2. In some embodiments, after a business process contract is deployed in the blockchain network, the scheduling process creates a compute service process that services the business process contract according to the content of the business process contract and based on the compute function code of each compute type.

3. In some embodiments, the scheduling process may determine whether at least one computing service process corresponding to the computing type and in an occupiable state runs on the corresponding node device; if the judgment result is yes, one of the calculation service processes is dispatched to be the calculation service process occupied by the calculation task; if the judgment result is negative, under the condition that the equipment limitation condition is met, a computing service process corresponding to the computing type and in an occupiable state is created based on the basic computing function code corresponding to the computing type deployed on the corresponding node equipment, and the started computing service process is scheduled to be the computing service process occupied by the computing task.

The computing service process is in an occupiable state, which can be understood as: the computing service process is not occupied by any computing task; or the computing service process is not occupied by N computing tasks simultaneously, and N is the maximum value of the number of the computing tasks capable of occupying the computing service process.

Wherein the device limitation condition may be: the number of the computing service processes running on the corresponding node equipment does not exceed the upper limit of the number; the upper limit of the number is determined according to the performance level of the corresponding node device.

Further, when a computing service process is created for a certain computing task, if the computing task specifies a service scenario configuration, on the basis of a computing function code corresponding to the computing type deployed on a corresponding node device, in combination with the service scenario configuration specified by the computing task, a computing service process corresponding to the computing type and in an occupiable state is created; if the computing task does not specify the business scene configuration, a computing service process corresponding to the computing type and in an occupiable state is created based on the basic computing function code corresponding to the computing type deployed on the corresponding node equipment.

4. In some embodiments, a computing service process may be temporarily scheduled for at least some of the computing tasks in a business process contract each time a business transaction invoking the business process contract is received by the blockchain network. That is, for any computing task, the computing service process occupied by the computing task is created after the business process contract is invoked by the business transaction. And after the business transaction is processed, removing the occupation relationship of the business process contract on the computing service processes. In this manner, computing service process resources on the node device may be fully utilized.

5. In some embodiments, the scheduling process may temporarily schedule a compute service process for a compute task whenever the compute task in the business process contract is to be executed, and the compute service process is deallocated from the compute task after the execution of the compute task is completed. Specifically, for each calculation task defined in the business process contract, the scheduling process corresponding to the node participating in the calculation task releases the occupation state of the calculation task on the calculation service process after obtaining the calculation result returned by the calculation service process occupied by the calculation task. Therefore, the utilization efficiency of the computing service process resources on the node equipment can be further improved.

In addition, in some embodiments, for any one computing task, if there is more than one node participating in the computing task, the computing task is implemented in a cooperative manner by computing service processes occupied by the computing task corresponding to the nodes participating in the computing task.

The cooperation mode can be specifically a multi-party safe computing mode. In practical application, members corresponding to nodes participating in the same computing task may need to contribute data collected by themselves to participate in computing, and in view of data security, the members corresponding to the nodes participating in the same computing task need to cooperate with each other to complete the computing task by using computing service processes of the same computing type deployed on respective node devices on the premise that data does not exist in a domain. In addition, the above-mentioned collaboration mode may be another mode requiring cooperation of multiple parties.

Fig. 8 is a flowchart of a business execution method based on an out-of-chain computing service provided in the present specification, including the following steps:

step S800: and each node in the block chain network acquires the service transaction for calling the service flow contract.

In the following description of the method shown in fig. 8, the creation opportunities of the computing service processes are not focused. In summary, before starting to execute step S800, for at least part of (each of) the computing tasks defined in the business process contract, the node device running the node participating in the computing task further runs thereon: the computing task occupies a computing service process and a scheduling process for scheduling the computing service process.

Business transactions typically specify business parameters as input to business process contracts.

Step S802: each node in the block chain network executes the service flow contract according to the service transaction: and for at least part of the computing tasks defined in the business process contract, if the starting conditions of the computing tasks are determined to be met, triggering request events for the computing tasks.

The "at least partial computation task" herein may be all computation tasks in the business process contract or a partial computation task. In step S802, each of at least some of the computing tasks is referred to.

The node executes the business process contract according to the transaction, namely executing each calculation task in the business process contract according to the transaction. For a computing task at least partially occupying an out-of-chain computing service process, once a node judges that a starting condition of the computing task is met, a request event for the computing task is triggered based on an event message mechanism of a contract.

Wherein, the starting condition of the computing task can be specified according to actual needs. In some embodiments, if the computing tasks in the business process contract can logically form the directed graph structure described above, the starting condition for any computing task may be that every other computing task connected to the incoming edge of the computing task has been completed.

Further, if the computing task requires input, the message for the request event of the computing task includes the input of the computing task.

In addition, if the node judges that the starting condition of the computing task is not met, the node does not trigger a request event aiming at the computing task.

Step S804: and after monitoring the request event, the scheduling process corresponding to each node participating in the computing task calls the computing service process occupied by the computing task.

For the scheduling process corresponding to the node which does not participate in the computing task, after the request event is monitored, the request event may not be processed, and the message of the request event is discarded.

In some embodiments, for any computing task, if multiple nodes participate, the computing service processes occupied by the computing task distributed on different node devices may execute the computing task in a cooperative manner.

Step S806: and the scheduling process corresponding to the node acquires the calculation result returned by the calculation service process.

Step S808: and the scheduling process corresponding to the node submits the calculation result transaction for calling the service flow contract to the block chain network based on the calculation result.

The calculation result transaction may bring the calculation result into a business process contract to advance the business process to the next calculation task.

Through the method flows shown in fig. 7 and fig. 8, in the process of executing the business process contract by the node, each calculation task does not need to be directly executed, but at least part of the calculation tasks are directly executed by a calculation service process independent of the node, so that the dependency of the propulsion efficiency of the business process on the running state of the node is weakened, and the propulsion of the business process is not easily delayed even if the node runs abnormally. In addition, even if a certain computing task is abnormally executed, the abnormal repair of the node is not needed, and the running state of the node is not easily influenced.

In addition, in practical applications, some users without administrator rights may need to implement some business processes of the users themselves by means of the computing power of the node devices of some members in the blockchain system, and therefore, these users usually need to request to create a blockchain subnet in the blockchain system. To this end, the present specification provides a method for creating a blockchain subnet, which is used for implementing a user without administrator authority to initiate a blockchain subnet, and the method includes:

1. and each main network node respectively acquires a sub-network creation transaction for calling the local network governance contract.

Wherein, each main network node can be deployed with a local network administration contract and a sub-network management contract. The local network governance contract is an intelligent contract used for governing all matters occurring in the local network. The "home network" herein refers to the blockchain network itself deployed by the intelligent contract. Besides the main network, any blockchain sub-network can also be deployed with a local network governance contract for governance of various events occurring in the blockchain sub-network.

The governance here may include governance of the behavior of creating the subnet in the home network, and particularly relates to a mechanism for voting for the matter of creating the subnet in the home network. In addition to voting for items created by the sub-network, in some embodiments, voting may be performed for items such as adding or deleting nodes in the home network, contract deployment in the home network, and contract update already deployed in the home network.

The subnet management contract refers to an intelligent contract for managing the next-level subnet of the local network, and the management here may include creating the next-level subnet, and may also include closing the next-level subnet, adding a node to the next-level subnet, deleting a node from the next-level subnet, and the like.

A user without administrator authority can construct a subnet creation transaction through a client of the user and submit the subnet creation transaction to a main network, wherein the subnet creation transaction specifies subnet configuration information, and the subnet configuration information comprises: identity information of a plurality of members participating in the sub-network to indicate on which member's node devices the main network should create a new sub-network node to compose the sub-network.

And the subnet creation transaction also needs to specify the called contract as a home network governance contract deployed in the main network, so that the home network governance contract triggers a voting mechanism for the subnet creation items.

2. Each main network node executes a local network governance contract: triggering a voting event that creates a transaction for the subnet.

3. And after monitoring the voting event, each voting party client judges whether to permit the subnet to establish a transaction, and submits the voting transaction for calling a local network governing contract to the main network based on the judgment result.

4. And each main network node continues to execute the local network governance contract: and calling a subnet management contract under the condition of determining the passing of votes according to the received voting transactions.

Intelligent contracts typically support event mechanisms, providing an ability for intelligent contracts within a chain to interact with outside the chain. The method comprises the steps that an event in the blockchain network can be monitored outside the blockchain network, and a transaction for calling the intelligent contract is submitted to the blockchain network in response to the monitored event, so that the purpose of providing parameters for the intelligent contract in response to the requirement of the intelligent contract is achieved.

Each master network node triggers a voting event aiming at the subnet creation transaction in the process of executing the local network governance contract according to the subnet creation transaction, and the message of the voting event usually contains subnet configuration information specified by the subnet creation transaction. Each voting party client can monitor the message of the voting event and judge whether to permit the subnet to create the transaction according to the subnet configuration information of the subnet to be created.

It should be noted that the identity of the voting party can be specified according to actual needs. Generally, each voter may be each user with administrator authority, and the administrator user may be the member itself or some other user authorized by the member.

Furthermore, from a membership perspective, the identity of each voter may include the following: all members of the system; or, a partial member of the system; or, a partial member of the system with at least one non-member; alternatively, all members of the system are associated with at least one non-member; alternatively, a plurality of non-members.

The voting party client judges whether to permit the subnet to establish a transaction mode, specifically, the corresponding subnet configuration information is displayed to the voting party, and an instruction (agreement or disagreement) input by the voting party is received; or judging whether to permit according to a preset judgment rule.

And each voting party client encapsulates the judgment result into the voting transaction and submits the voting transaction to the main network. The voting transaction also requires the invocation of the home network governance contract.

And each main network node receives the voting transaction submitted by each voting party client based on the process of executing the local network administration contract, counts the voting result, calls a subnet management contract through the local network administration contract in a mutual calling mode among the contracts if the voting result is characterized to pass (namely, the subnet is agreed to be constructed), and transmits the subnet configuration information to the subnet administration contract through an interface among the contracts so as to establish the subnet through the subnet management contract.

5. Each master network node executes a subnet management contract: and triggering a subnet creating event according to the subnet configuration information.

6. And the master network node on each node device participating in the member of the sub-network deploys the sub-network node after monitoring the sub-network creation event.

And in the process that the main network node executes the called subnet management contract, the event mechanism is continuously utilized to trigger a subnet creation event, and the message of the event contains subnet configuration information.

Each main network node monitors a subnet creating event, whether the subnet configuration information contains the identity information of the member corresponding to the equipment can be judged, if not, the processing is not needed, and if yes, the subnet node is deployed in the equipment.

In addition, in some embodiments, the master network node on each node device participating in a member of the subnet may write the subnet configuration information into the created block of the block chain maintained by the subnet node when the subnet node is deployed.

In practical applications, after the creation of the subnet, a user requesting to create the subnet will also gradually deploy several business process contracts in the subnet. For safety, each member in the blockchain system expects that when a user requests to create a subnet, a service flow contract to be subsequently deployed in the subnet is pre-registered, so that safety management and control are facilitated. Only pre-registered business process contracts deployed by users in the subnet are allowed after subnet creation.

To this end, in some embodiments, the subnet configuration information specified by the subnet creation transaction may also include contract preregistration information; the contract pre-registration information includes: allowing clear text or contract hashing of one or more business process contracts deployed in the created subnet. It should be noted here that if the pre-registration information includes a contract hash, the effect that the user does not expose the contract plaintext to the main network, but only exposes the created sub-network can be achieved.

Further, the contract pre-registration information may also include a contract identification that allows one or more business process contracts to be deployed in the created subnet.

Additionally, where included in the contract pre-registration information is a contract hash, the contract pre-registration information may also include a business process profile corresponding to one or more business process contracts that are allowed to be deployed in the created subnet.

In the case where contract preregistration information is included in the foundational block of the created subnet, the manner of deploying the business process contract into the subnet may be:

each subnet node in the created block chain subnet respectively acquires service flow contract deployment transaction; verifying whether the contract hash of the business process contract appointed by the business process contract deployment transaction is recorded in the contract pre-registration information in the creation block; if yes, deploying a business process contract appointed by the business process deployment transaction; if not, refusing to deploy the business process contract appointed by the business process deployment transaction.

In some embodiments, after the blockchain subnet is created, a networkaround contract may be deployed in the blockchain subnet. And when a business process contract is required to be deployed in the blockchain subnet subsequently, submitting a business process contract deployment transaction for calling an intelligent contract of the local network to the blockchain subnet, and triggering voting by a local network governance contract to determine whether the business process contract designated by the business process contract deployment transaction can be deployed in the blockchain subnet or not based on the voting mechanism. It should be noted that each voting party may vote by referring to the contract preregistration information in the creation block of the block chain subnet.

It should be noted that, in the method shown in fig. 8, the creation block of the blockchain network may include contract pre-registration information, where the contract pre-registration information includes: allowing contract hashing of one or more business process contracts deployed in the blockchain network. In this way, the mode of deploying the business process contract for the blockchain network may specifically be that a node of the blockchain network obtains a business process contract deployment transaction; verifying whether the contract hash of the business process contract appointed by the business process contract deployment transaction is recorded in the contract pre-registration information in the creation block; if yes, deploying a business process contract appointed by the business process deployment transaction; if not, refusing to deploy the business process contract appointed by the business process deployment transaction.

In addition, in some embodiments, the next-level sub-network of the main network may also deploy its own local network administration contract and sub-network management contract. That is, similar to the process of the main network creating the next subnet, the subnet may also create a more own next subnet. Specifically, the method comprises the following steps:

for any block chain sub-network in the system, each sub-network node of the block chain sub-network respectively acquires a sub-network creation transaction for calling a local network governing contract; the subnet creation transaction specifies subnet configuration information, including: identity information of a plurality of members participating in the subnet;

each sub-network node executes a local network management contract: triggering a voting event that creates a transaction for the subnet;

after monitoring the voting event, each voting party client judges whether to permit the subnet to establish a transaction, and submits the voting transaction for calling a local network governing contract to the block chain subnet based on the judgment result;

and each sub-network node continuously executes the local network management contract: according to the received voting transactions, under the condition of determining that the votes pass, calling a subnet management contract;

each sub-network node executes a sub-network management contract: triggering a subnet creating event according to the subnet configuration information;

and each sub-network node on the node equipment participating in the member of the sub-network deploys the sub-network node after monitoring the sub-network creation event.

It should be noted that, in the embodiment where the subnet creates the next-level subnet, the creation block of the created next-level subnet may also include contract pre-registration information, and the business process contract that is allowed to be subsequently deployed in the created next-level subnet also needs to be matched with the contract pre-registration information. The embodiments of how to deploy the service flow contract in the created next-level subnet can be understood with reference to the foregoing, and are not described here again.

The flow diagram of another method for creating a blockchain subnet provided in the embodiment of the present specification includes the following steps:

Each main network node is provided with a local network administration contract, a subnet management contract and a business process management contract.

The business process management contract is used for recording the corresponding relation between the created subnet and the contract pre-registration information and can provide the function of inquiring the corresponding relation.

The subnet creation transaction specifies subnet configuration information, including: identity information and contract pre-registration information of a plurality of members participating in the subnet; the contract pre-registration information includes: contract hashing that allows one or more business process contracts to be deployed in the created subnet.

The method is mainly different from the prior subnet establishing method in that a service process management contract is also arranged on a main network node, the subnet management contract is not called any more in the process of processing the subnet establishing transaction, but the process management contract is called under the condition of determining the passing of the vote, the subnet configuration information is transmitted to the process management contract, then the process management contract calls the subnet management contract (the subnet configuration information is further transmitted to the subnet management contract) to establish the subnet, and the process management contract records the corresponding relation between the established subnet and the contract pre-registration information.

4. And each main network node continues to execute the local network governance contract: and calling a business process management contract under the condition of determining the passing of votes according to the received voting transactions.

5. Each main network node executes a business process management contract: and calling a subnet management contract, and saving the corresponding relation between the network identification of the subnet to be created and the contract pre-registration information.

It should be noted that, in some embodiments, the process management contract allocates the network identifier to the subnet to be created, and establishes a corresponding relationship between the network identifier and the contract pre-registration information. In other embodiments, the subnet management contract assigns the subnet identifier to the subnet to be created, in which case the subnet management contract needs to return the subnet identifier to the process management contract after being invoked by the process management contract.

6. Each master network node executes a subnet management contract: and triggering a subnet creating event according to the subnet configuration information.

7. And the master network node on each node device participating in the member of the sub-network deploys the sub-network node after monitoring the sub-network creation event.

Further, the user may query the contract pre-registration information recorded in the business process contract of the primary network node corresponding to each sub-network to see which contracts are allowed to be deployed on each sub-network created by the primary network.

Specifically, each main network node respectively acquires inquiry transaction of a call flow management contract; the query transaction specifies a network identification of a subnet created by the primary network; each main network node executes a process management contract: inquiring the contract pre-registration information corresponding to the network identification, and returning the inquired contract pre-registration information to the client side submitting the inquiry transaction.

In addition, the subnet created by the main network may further create a next-level subnet, specifically:

each subnet node of any block chain subnet respectively acquires a subnet establishment transaction for calling a local network governing contract; the subnet creation transaction specifies subnet configuration information, including: identity information and contract pre-registration information of a plurality of members participating in the subnet; the contract pre-registration information includes: allowing contract hashing of one or more business process contracts deployed in the created subnet;

and each sub-network node continuously executes the local network management contract: according to the received voting transactions, under the condition of determining that the votes pass, calling a business process management contract;

each sub-network node executes a business process management contract: calling a subnet management contract, and storing a corresponding relation between a network identifier of a subnet to be created and contract pre-registration information;

In addition, in practical application, only one intelligent contract may be deployed on the main network, and the intelligent contract integrates the functions of the local network administration contract, the sub-network management contract and the business process management contract described above. Such a method comprises:

1. and each main network node respectively acquires a subnet establishment transaction for calling the intelligent contract.

The subnet creation transaction specifies subnet configuration information, including: identity information of a plurality of members participating in the subnet;

2. each main network node executes an intelligent contract: triggering a voting event that creates a transaction for the subnet.

4. And each main network node continues to execute the intelligent contract: and triggering a subnet creating event according to the subnet configuration information under the condition that the votes are determined to pass according to the received voting transactions.

5. And the master network node on each node device participating in the member of the sub-network deploys the sub-network node after monitoring the sub-network creation event.

Further, the subnet configuration information further includes: contract pre-registration information; the contract pre-registration information includes: contract hashing that allows one or more business process contracts to be deployed in the created subnet.

Further, in the process that each main network node executes the intelligent contract, the corresponding relation between the network identification of the sub-network to be created and the contract pre-registration information can be stored.

Furthermore, each main network node respectively acquires inquiry transactions for calling the intelligent contracts; the query transaction specifies a network identification of a subnet created by the primary network; each main network node executes an intelligent contract: inquiring the contract pre-registration information corresponding to the network identification, and returning the inquired contract pre-registration information to the client side submitting the inquiry transaction.

In addition, an apparatus for scheduling computing services for a business process contract is provided, where a business process contract is deployed on a blockchain network, the business process contract defining each computing task for implementing a business process and specifying at least one node participating in each computing task; the method is applied to a scheduling process which is also operated on node equipment corresponding to each node, and the device comprises the following steps:

A blockchain network is provided, on which a business process contract is deployed, the business process contract defining therein each computing task for implementing a business process and specifying at least one node participating in each computing task;

A blockchain network is provided, on which a business process contract is deployed, the business process contract defining therein each computing task for implementing a business process and specifying at least one node participating in each computing task; for at least part of the computing tasks defined in the business process contract, running on the node devices of the nodes participating in the computing tasks is also executed: a computing service process occupied by the computing task and a scheduling process for scheduling the computing service process;

each node in the block chain network acquires the service transaction for calling the service flow contract, and executes the service flow contract according to the service transaction: for at least part of the calculation tasks, if the calculation tasks are participated in and the starting conditions of the calculation tasks are met, triggering request events aiming at the calculation tasks;

the scheduling process corresponding to each node calls a computing service process occupied by the computing task after monitoring the request event; and acquiring a calculation result returned by the calculation service process, and submitting the calculation result transaction for calling the business process contract to the block chain network based on the calculation result.

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 invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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 present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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 method for scheduling computation service for a business process contract, a business process contract is deployed on a block chain network, each computation task for realizing a business process is defined in the business process contract, and at least one node participating in each computation task is specified; the method is applied to a scheduling process which is also operated on node equipment corresponding to each node, and comprises the following steps:

2. The method of claim 1, wherein the blockchain network is any blockchain network in a blockchain system participated by a plurality of members; the system comprises node equipment of each member on a hardware level, at least one node is deployed on the node equipment of each member, and different nodes deployed on the node equipment of the same member belong to different block chain networks; the system has a tree structure with the block chain main network as a root node and each block chain sub-network as other nodes in a software layer.

3. The method as claimed in claim 1, wherein different computing service processes corresponding to the same computing type are created by combining different service scenario configurations on the basis of the computing function code corresponding to the computing type, and are used for executing computing tasks in different service scenarios.

4. The method of claim 1, wherein scheduling a compute service process running on a corresponding node device in an occupiable state corresponding to the compute type as a compute service process occupied by the compute task, comprises:

judging whether at least one computing service process corresponding to the computing type and in an occupiable state runs on the corresponding node equipment;

if the judgment result is yes, one of the calculation service processes is dispatched to be the calculation service process occupied by the calculation task;

if the judgment result is negative, under the condition that the equipment limitation condition is met, a computing service process corresponding to the computing type and in an occupiable state is created based on the basic computing function code corresponding to the computing type deployed on the corresponding node equipment, and the started computing service process is scheduled to be the computing service process occupied by the computing task.

5. The method of claim 4, wherein one or more of the computing tasks defined in the business process contract specify a business scenario configuration;

starting a computing service process corresponding to the computing type and in an occupiable state based on a basic computing function code corresponding to the computing type deployed on corresponding node equipment, wherein the process comprises the following steps:

if the computing task specifies the business scene configuration, on the basis of a computing function code corresponding to the computing type deployed on corresponding node equipment, and in combination with the business scene configuration specified by the computing task, a computing service process corresponding to the computing type and in an occupiable state is created;

if the computing task does not specify the business scene configuration, a computing service process corresponding to the computing type and in an occupiable state is created based on the basic computing function code corresponding to the computing type deployed on the corresponding node equipment.

6. The method of claim 4, wherein the device constraints comprise: the number of the computing service processes running on the corresponding node equipment does not exceed the upper limit of the number; the upper limit of the number is determined according to a performance level of the corresponding node device.

7. The method of claim 1, wherein the computing service process is in an occupiable state, comprising:

the computing service process is not occupied by any computing task;

or

The computing service process is not occupied by N computing tasks simultaneously, N is the maximum value of the number of the computing tasks capable of occupying the computing service process, and N is larger than 1.

8. The method according to claim 1, wherein for any one computing task, if there is more than one node participating in the computing task, the computing task is implemented in a cooperative manner by using a computing service process occupied by the computing task corresponding to each node participating in the computing task.

9. The method of claim 1, wherein the creation block of the blockchain network comprises contract pre-registration information, the contract pre-registration information comprising: allowing contract hashing of one or more business process contracts deployed in the blockchain network.

10. The method of claim 9, deploying a business process contract for the blockchain network, comprising:

the nodes of the block chain network acquire service process contract deployment transactions;

verifying whether the contract hash of the business process contract appointed by the business process contract deployment transaction is recorded in the contract pre-registration information in the creation block;

if yes, deploying the business process contract appointed by the business process deployment transaction.

11. The method of claim 1, wherein the node device corresponding to the node comprises: a single device or a cluster of devices.

12. The method of claim 1, wherein the blockchain network is a public chain network or a alliance chain network.

13. An apparatus for scheduling computing services for a business process contract, a business process contract deployed on a blockchain network, the business process contract defining each computing task for implementing a business process and specifying at least one node participating in each computing task; the device is applied to a scheduling process which is operated on node equipment corresponding to each node, and comprises the following steps:

14. A blockchain system comprises a blockchain network, wherein a business process contract is deployed on the blockchain network, each computing task for realizing a business process is defined in the business process contract, and at least one node participating in each computing task is specified;