WO2022252995A1

WO2022252995A1 - Smart contract deployment method and apparatus

Info

Publication number: WO2022252995A1
Application number: PCT/CN2022/093802
Authority: WO
Inventors: 郭学鹏
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2021-06-02
Filing date: 2022-05-19
Publication date: 2022-12-08
Also published as: CN113067900B; CN113067900A

Abstract

Provided in one or more embodiments of the present description are a smart contract deployment method and apparatus. The method comprises: acquiring a task code generated by means of describing a workflow by using a workflow description language; compiling the task code by means of a compiler, so as to generate a contract code for representing the workflow; and sending, to a blockchain network, a blockchain transaction for deploying the contract code, so as to deploy a corresponding smart contract in the blockchain network, wherein the smart contract is used for allocating, when being called and according to service logic defined by each task node in the workflow, a task to be executed to a node member which participates in the blockchain network.

Description

Method and device for smart contract deployment

technical field

The embodiment of this specification relates to the field of blockchain technology, and in particular to a method and device for smart contract deployment.

Background technique

Blockchain technology is built on top of transmission networks such as peer-to-peer networks. Nodes in the blockchain network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data. In some blockchain networks, some nodes sometimes need to implement small-scale transactions to prevent other nodes from obtaining these transactions and their related data. Therefore, a blockchain subnet can be further established on the basis of the blockchain main network.

Smart contracts corresponding to specific businesses can be deployed in the blockchain main network or blockchain subnet. In related technologies, the contract code of smart contracts is usually written by users or technicians through manual programming. Therefore, the standardization of smart contract codes is low, which is not conducive to the generation and execution of smart contracts, and limits the deployment and execution efficiency of smart contracts. .

Contents of the invention

In view of this, one or more embodiments of this specification provide a smart contract deployment method and device.

In order to achieve the above purpose, according to the first aspect of one or more embodiments of this specification, a smart contract deployment method is proposed, including: obtaining the task code generated by using the workflow description language to describe the workflow; Compile the task code to generate a contract code representing the workflow; send a blockchain transaction for deploying the contract code to the blockchain network to deploy the corresponding task code in the blockchain network The smart contract is used to assign tasks to be executed to the node members participating in the blockchain network according to the business logic defined by each task node in the workflow when called.

According to the second aspect of one or more embodiments of this specification, a smart contract deployment method is proposed, which is applied to the blockchain nodes in the blockchain network, including: responding to the received blockchain deployment contract code transaction, deploying the corresponding smart contract in the blockchain network; the contract code is generated by compiling the task code by the compiler, and the task code is generated by describing the workflow in the workflow description language; in response to The received block chain transaction calling the smart contract assigns tasks to be executed to the node members participating in the block chain network according to the business logic defined by each task node in the workflow.

According to a third aspect of one or more embodiments of the present specification, a smart contract deployment device is proposed, including: a code acquisition unit that acquires the task code generated by describing the workflow using a workflow description language; a code compilation unit , so that the task code is compiled by the compiler to generate the contract code used to represent the workflow; the transaction deployment unit is used to send the blockchain transaction used to deploy the contract code to the blockchain network to Deploy the corresponding smart contract in the blockchain network, and the smart contract is used to report to the node members participating in the blockchain network according to the business logic defined by each task node in the workflow when called Assign pending tasks.

According to a fourth aspect of one or more embodiments of this specification, a smart contract deployment device is proposed, which is applied to a blockchain node in a blockchain network, including: a contract deployment unit that responds to the received deployment contract The blockchain transaction of the code, deploy the corresponding smart contract in the blockchain network; the contract code is generated by compiling the task code by the compiler, and the task code describes the workflow by the workflow description language and generate; the contract invoking unit responds to the block chain transaction of calling the smart contract received, according to the business logic defined by each task node in the workflow, to the node members participating in the block chain network Assign pending tasks.

According to a fifth aspect of one or more embodiments of the present specification, an electronic device is provided, including: a processor; a memory for storing processor-executable instructions; wherein, the processor executes the executable instructions To realize the method described in the first aspect or the second aspect.

According to a sixth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the method described in the first aspect or the second aspect is implemented. A step of.

Description of drawings

Fig. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.

Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of creating and invoking a smart contract provided by an exemplary embodiment.

Fig. 4 is a schematic diagram of building a blockchain subnet based on the blockchain main network provided by an exemplary embodiment.

Fig. 5 is a flowchart of a smart contract deployment method provided by an exemplary embodiment.

Fig. 6 is a flowchart of another smart contract deployment method provided by an exemplary embodiment.

Fig. 7 is a flowchart of another smart contract deployment method provided by an exemplary embodiment.

Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 9 is a block diagram of a smart contract deployment device provided by an exemplary embodiment.

Fig. 10 is a block diagram of another smart contract deployment device provided by an exemplary embodiment.

Detailed ways

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, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other combinations. Among them, the public chain has the highest degree of decentralization. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the bookkeeping rights of new blocks. Moreover, each participant (ie node) can freely join and exit the network and perform related operations. On the contrary, the private chain, the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use by specific institutions. The alliance chain is a blockchain between the public chain and the private chain, which can realize "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; participants join the network through authorization and form an alliance of stakeholders to jointly maintain the operation of the blockchain.

Whether it is a public chain, a private chain or an alliance chain, it is possible to provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered by transactions on the blockchain system. Smart contracts can be defined in the form of code.

Taking Ethereum as an example, it supports users to create and invoke some complex logic in the Ethereum network, which is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and each Ethereum node can run the EVM. EVM is a Turing-complete virtual machine, which means that various complex logic can be implemented through it. Users publish and call smart contracts in Ethereum that run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as “bytecode”). Smart contracts deployed on the blockchain can be in the form of bytecode.

For example, as shown in Figure 1, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. "0x6f8ae93..." in Figure 1 represents the address of this contract, the data field of the transaction can store bytecode, and the to field of the transaction is empty. After the nodes reach a consensus through the consensus mechanism, the contract is successfully created and can be called in the subsequent process. After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code will be saved in the contract account. The behavior of smart contracts is controlled by the contract code. In other words, the smart contract makes a virtual account containing contract code and account storage (Storage) generated on the blockchain.

As shown in Figure 2, still taking Ethereum as an example, after Bob sends a transaction for calling a smart contract to the Ethereum network, the EVM of a certain node can execute this transaction and generate a corresponding contract instance. The from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93..." in the to field represents the address of the called smart contract, and the value field is the value of Ethereum in Ethereum. The method and parameters of calling the smart contract are saved in the data field of the transaction. After calling the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance through a certain blockchain node (such as node 6 in Figure 2). Smart contracts are independently executed by each node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will store data that cannot be tampered with and will not be tampered with. Lost transaction credentials.

The schematic diagram of creating a smart contract and calling a smart contract is shown in Figure 3. To create a smart contract in Ethereum, you need to go through the process of writing a smart contract, compiling it into bytecode, and deploying it to the blockchain. Calling a smart contract in Ethereum is to initiate a transaction pointing to the address of the smart contract, and the code of the smart contract is distributed and runs in the virtual machine of each node in the Ethereum network.

It should be noted that in addition to creating smart contracts by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some blockchain network data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts). In addition to the EVM in Ethereum, different blockchain networks may also use various virtual machines, which are not limited here.

After the nodes in the blockchain network execute the transaction that invokes the smart contract, they will generate a corresponding receipt (receipt), which is used to record information related to the execution of the smart contract. In this way, information about the contract execution result can be obtained by querying the receipt of the transaction. Contract execution results can be expressed as events in receipts. The message mechanism can implement message delivery through events in the receipt to trigger blockchain nodes to perform corresponding processing. The structure of an event can be, for example:

Event:

[topic][data]

…

In the above example, there may be one or more events; each event includes fields such as topic and data. Blockchain nodes can listen to the topic of the event to perform preset processing when listening to a predefined topic, or read relevant content from the data field of the corresponding event, and can execute preset based on the read content deal with.

In the above event mechanism, it is equivalent to the presence of a client with monitoring function at the listening party (such as a user with a monitoring requirement). The events generated by the block chain nodes are monitored, and the block chain nodes only need to generate receipts normally. In addition to the above-mentioned event mechanism, transaction information disclosure can also be realized in other ways. For example, the monitoring code can be embedded in the blockchain platform code running on the blockchain node, so that the monitoring code can monitor the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc. or multiple types of data, and send the monitored data to a predefined listener. Since the monitoring code is deployed in the blockchain platform code instead of the listener's client, this implementation based on the monitoring code is relatively more active than the event mechanism. Among them, the above monitoring code can be added to the blockchain platform code by the developers of the blockchain platform during the development process, or can be embedded by the monitoring party based on its own needs, which is not limited in this manual.

One of the decentralized features of blockchain technology that distinguishes it from traditional technologies is that bookkeeping is performed on each node, or called distributed bookkeeping, rather than traditional centralized bookkeeping. In order for the blockchain system to become a decentralized, honest and credible system that is difficult to break, open, and cannot be tampered with data records, it is necessary to make distributed data records safe, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, the aforementioned consensus mechanism. For example, a block-granularity consensus mechanism can be implemented between blockchain nodes. For example, after a node (such as 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 consensus mechanism of transaction granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, Each node that approves the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and finally can ensure that each node generates the same latest block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) in the entire network, 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 Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, HoneyBadgerBFT algorithm, etc.

Due to the decentralized nature of the blockchain network, all blockchain nodes in the blockchain network will maintain the same block data, which cannot meet the special needs of some nodes. Taking the consortium chain as an example, all consortium members (that is, node members in the consortium) can form a blockchain network, and all consortium members have corresponding blockchain nodes in the blockchain network, and can pass the corresponding zone Block chain nodes obtain all transactions and related data that occur on the block chain network. However, in some cases, there may be some alliance members who want to complete some transactions that require confidentiality. These alliance members hope that these transactions can be stored on the blockchain or take advantage of other advantages of blockchain technology, and can avoid other transactions. Affiliate members see these transactions and related data. Although these alliance members can additionally form a new blockchain network, the establishment method is similar to the above-mentioned blockchain network that includes all alliance members, but building a new blockchain network from scratch requires a lot of resources, and regardless of The establishment process of the blockchain network or the configuration process after completion is very time-consuming. The needs among alliance members are often temporary or have a certain timeliness, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network . However, the needs of alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever the alliance members change, it may be necessary to form a new blockchain network, resulting in resource and time constraints. A lot of waste.

To this end, the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be formed on the basis of the blockchain main network. Then, in the consortium chain scenario such as the one mentioned above, the consortium members can build the required blockchain subnet based on their own needs while already participating in the blockchain main network. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet is compared to the completely independent establishment of a blockchain network, the resources consumed and the time required, etc. Both are greatly reduced, and the flexibility is extremely high.

The process of quickly establishing a blockchain subnet based on the blockchain main network is as follows: each main network node in the blockchain main network obtains a transaction for establishing a blockchain subnet, and the transaction includes the configuration information of the blockchain subnet , the configuration information includes identity information of node members. Then, each main network node in the blockchain main network respectively executes the transaction; wherein, when the first main network node belongs to the node member indicated by the configuration information, the node device of the first main network node is deployed A genesis block containing the configuration information is generated based on the transaction and a first subnetwork node belonging to the blockchain subnetwork is started.

The transaction of establishing a blockchain subnet can be initiated by the administrator of the blockchain main network, that is, only the administrator is allowed to establish a blockchain subnet on the basis of the blockchain main network, and avoid opening the establishment authority of the blockchain subnet to Normal users to prevent security issues caused by this. In some cases, ordinary users of the blockchain main network can also be allowed to initiate the above-mentioned transaction of establishing a blockchain subnet to meet the networking needs of ordinary users, so that ordinary users can still initiate transactions when the administrator is inconvenient. It is possible to quickly form a blockchain subnet.

Taking Figure 4 as an example, the blockchain main network is subnet0, and the blockchain nodes contained in subnet0 are nodeA, nodeB, nodeC, nodeD, and nodeE. Assume that nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to form a blockchain subnet, then nodeA can initiate the above-mentioned transaction to form a blockchain subnet to subnet0; If nodeE is an administrator and only allows the administrator to initiate the transaction of establishing a blockchain subnet, then nodeA~nodeD needs to make a request to nodeE, so that nodeE initiates the above transaction of establishing a blockchain subnet to subnet0; if nodeE is an administrator but allows Ordinary users initiate a transaction to establish a blockchain subnet, then nodeA～nodeE can initiate the above transaction to subnet0 to establish a blockchain subnet. Of course, whether it is an administrator or an ordinary user, the blockchain node that initiates the transaction to form a blockchain subnet does not necessarily participate in the established blockchain subnet. network, but nodeE can initiate the above-mentioned transaction of establishing a blockchain subnet to subnet0, and not necessarily nodeA~nodeD initiate the transaction of establishing a blockchain subnet.

When a blockchain subnet is established on the basis of the blockchain main network, it is easy to understand that there will be a logical hierarchical relationship between the blockchain subnet and the blockchain main network. For example, when building a blockchain subnet subnet1 on subnet0 shown in Figure 4, it can be considered that subnet0 is in the first layer, subnet1 is in the second layer, subnet0 is the parent network of subnet1, and subnet1 is the subnet of subnet0. And the blockchain subnet can also form a corresponding blockchain subnet. For example, another blockchain subnet subnet3 can be further established on the basis of subnet1 in Figure 4. At this time, it can be considered that the subnet is in the third layer, and subnet1 is the corresponding subnet3. The parent network, subnet3 is the subnet of subnet1, and subnet3 is the grandson of subnet0. Similarly, subnet3 can still build a new blockchain subnet based on it, so that this multi-level tree can be formed between blockchain networks In this specification, any blockchain network is managed by its corresponding parent network, that is, it is managed by the blockchain network that forms any blockchain network. Therefore, as shown in Figure 4 A block chain subnet represented by any node in a block chain network tree system with the block chain main network as the root node (the root node has the lowest level) and each block chain subnet as other nodes The network is managed by the blockchain network corresponding to its parent node, and as a special case, when the blockchain main network is the underlying blockchain network, the blockchain main network is managed by the blockchain main network itself. The blockchain main network in this specification can be the underlying blockchain network. The underlying blockchain network refers to a blockchain subnet that is not established on the basis of other blockchain networks. Therefore, in addition to the blockchain main network There is no other blockchain network that can manage the blockchain main network. For example, subnet0 in Figure 4 can be considered as the blockchain main network of the underlying blockchain network type, and subnet0 manages subnet0 itself. Of course, the blockchain main network The network can also be a subnet of other blockchain networks, and this specification does not make any restrictions on this. The above-mentioned blockchain network tree system realizes layer-by-layer management through the parent node management of corresponding child nodes, which reduces the management pressure of the blockchain main network and avoids exposing the subnet information of the upper network to the lower network. In order to realize the secret management of the network at all levels.

After the above-mentioned transaction for establishing a blockchain subnet is sent to the blockchain main network, the consensus nodes in the blockchain main network will conduct a consensus, and after the consensus is passed, each main network node will execute the transaction to complete the block The formation of the chain subnet. The consensus process depends on the adopted consensus mechanism, such as any consensus mechanism mentioned above, which is not limited in this description.

By including the configuration information in the above-mentioned transaction of establishing the blockchain subnet, the configuration information can be used to configure the established blockchain subnet so that the established blockchain subnet meets the networking requirements. For example, by including the identity information of node members in the configuration information, it is possible to specify which blockchain nodes are included in the established blockchain subnet.

The identity information of the node members may include the public key of the node, or other information that can represent the identity of the node such as the node ID, which is not limited in this description. Taking the public key as an example, each blockchain node has one or more sets of corresponding public-private key pairs. The blockchain node holds the private key and the public key is public and uniquely corresponds to the private key. Therefore, it can be passed The public key is used to represent the identity of the corresponding blockchain node. Therefore, for blockchain nodes that want to be node members of the blockchain subnet, the public keys of these blockchain nodes can be added to the above-mentioned transaction of forming the blockchain subnet as the identity information of the above-mentioned node members.

The first main network node may be a blockchain node on the blockchain main network that is a node member indicated by the configuration information. When building a blockchain subnet, instead of the first main network node directly joining the blockchain subnet and becoming its node member, the first subnet node needs to be generated by the node device used to deploy the first main network node, And the first subnet node becomes a node member in the blockchain subnet. The first main network node and the first subnet node correspond to the same blockchain member, for example, in the alliance chain scenario, they correspond to the same alliance chain member, but the first main network node The node belongs to the blockchain subnet, so that the blockchain members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet belong to two independent Blockchain network, so that the blocks generated by the first main network node and the blocks generated by the first subnet node are respectively stored in different storages on the node device (the storage used can be a database, for example), realizing the first The storage used by the main network node and the first subnet node is isolated from each other, so the data generated by the blockchain subnet will only be synchronized among the node members of the blockchain subnet, so that only those who participate in the blockchain main The blockchain members of the network cannot obtain the data generated on the blockchain subnet, which realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies the requirements of some blockchain members (that is, the districts participating in the blockchain subnet). Transaction requirements between blockchain members).

It can be seen that the first main network node and the first subnet node are logically divided blockchain nodes, and from the perspective of physical equipment, it is equivalent to deploying the first main network node and the first subnet node The node devices participate in the blockchain main network and the blockchain subnet at the same time. Since the blockchain main network and the blockchain subnet are independent of each other, the identity systems of the two blockchain networks are also independent of each other, so even if the first main network node and the first subnet node can use exactly the same public key, the two should still be considered as different blockchain nodes. For example, in FIG. 4 , nodeA in subnet0 is equivalent to the first main network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 is equivalent to the first subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the first subnet node is different from that of the first main network node, it will not affect the implementation of the scheme in this specification.

Of course, the node members of the blockchain subnet are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network. At this time, all blockchain members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other. For example, by implementing one type of business on the blockchain main network and another type of business on the blockchain subnet, the two types of The business data generated by the business are isolated from each other.

In addition to the above-mentioned identity information of node members, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the The attribute configuration of the code, etc., is not limited in this manual. The network identifier is used to uniquely represent the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets formed on the blockchain main network. The identity information of the administrator of the blockchain subnet can be, for example, the public key of the node member who is the administrator; the administrators of the blockchain main network and the blockchain subnet can be the same or different.

One of the advantages of building a blockchain subnet through the blockchain mainnet is that since the first mainnet node has already been deployed on the node device that generates the first subnetwork node, the area used by the first mainnet node can be The block chain platform code is reused on the first subnet node, which eliminates the repeated deployment of the block chain platform code and greatly improves the efficiency of the block chain subnet. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node can reuse the attribute configuration adopted on the first main network node; if the configuration information includes the attribute configuration for the blockchain platform code attribute configuration, the first subnetwork node can adopt the attribute configuration, so that the attribute configuration adopted by the first subnetwork node is not limited to the attribute configuration of the first main network node, and has nothing to do with the first main network node. The attribute configuration for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., which are not limited in this specification.

Transactions that form blockchain subnets include transactions that call contracts. The transaction can specify the address of the called smart contract, the method called and the parameters passed in. For example, the invoked contract can be the aforementioned genesis contract or system contract, the invoked method can be a method for building a blockchain subnet, and the incoming parameters can include the above-mentioned configuration information. In one embodiment, the transaction may contain the following information:

from: Administrator

to: Subnet

method: AddSubnet(string)

string: genesis

Among them, the from field is the information of the initiator of the transaction. For example, Administrator indicates that the initiator is an administrator; the to field is the address of the called smart contract. For example, the smart contract can be a Subnet contract, and the to field is specifically the Subnet The address of the contract; the method field is the calling method. For example, the method used to build a blockchain subnet in the Subnet contract can be AddSubnet(string), and string is the parameter in the AddSubnet() method. In the above example, genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.

Take nodes nodeA~nodeE on Subnet0 executing a transaction calling the AddSubnet() method in the Subnet contract as an example. After the transaction passes the consensus, nodeA～nodeE respectively execute the AddSubnet() method and pass in the configuration information to obtain the corresponding execution results.

The execution result of the contract may include the configuration information, and the execution result may be included in the above-mentioned receipt, which may include an event related to the execution of the AddSubnet() method, that is, a networking event. The topic of networking events can contain predefined networking event identifiers to distinguish them from other events. For example, in the event related to the execution of the AddSubnet() method, the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods. Then, by monitoring the topics contained in each event in the generated receipt, nodeA~nodeE can determine to monitor the event related to the execution of the AddSubnet() method, that is, the networking event, when the topic containing the keyword subnet is monitored. For example, the event in the receipt is as follows:

Event:

[topic:other][data]

[topic:subnet][data]

…

Then, when nodeA~nodeE listens to the first event, because the content of the included topic is other, it is determined that the event has nothing to do with the AddSubnet() method; and, when nodeA~nodeE listens to the second event, because the content of the included The content of the topic is subnet, determine that the event is related to the AddSubnet() method, and then read the data field corresponding to the event, which contains the above configuration information. Taking the configuration information including the public key of the node member of the blockchain subnet as an example, the content of the data field may include, for example:

{subnet1;

The public key of nodeA, the IP of nodeA, the port number of nodeA...;

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

The public key of nodeC, the IP of nodeC, the port number of nodeC...;

The public key of nodeD, the IP of nodeD, the port number of nodeD...;

}

Among them, subnet1 is the network identifier of the blockchain subnet you want to create. Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets, such information can be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the values of one or more contract states included in the Subnet contract. Then, nodeA～nodeE can determine whether the above-mentioned subnet1 already exists according to the recorded network identifiers of all blockchain subnets that have been created; if it does not exist, it means that subnet1 is a new blockchain subnet that needs to be created currently, and if it exists, it means that subnet1 already exists.

In addition to adopting the network identifier of the new blockchain subnet you want to create, you can also use a predefined new network identifier, which indicates that the corresponding networking event is used to form a new blockchain subnet. For example, the above subnet1 can be replaced with newsubnet, which is a predefined new network identifier. When nodeA~nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created. Blockchain subnet.

In addition to the network identifier subnet1, the above data field also includes identity information of each node member and so on. The node device deploying the first main network node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member, the deployment second A node device of a main network node obtains the configuration information or the genesis block included in the networking event. For example, nodeA～nodeE will further identify the identity information of the node members contained in the data field in order to determine their own processing methods when they determine that subnet1 is a blockchain subnet that needs to be newly established. For example, nodeA~nodeD will find that the data field contains their own identity information such as their public key, IP address, and port number. Assume that nodeA~nodeD are deployed on node devices 1~4 respectively. Taking nodeA and node device 1 as an example: nodeA will Trigger node device 1, so that node device 1 obtains configuration information from the data field based on the above-mentioned message mechanism and generates a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and then nodeA1 will load the generated genesis block , thus forming a node member in subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. And, nodeE will find that the identity information contained in the data field does not match itself, assuming that nodeE is deployed on node device 5, then the node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1 nodes in .

As mentioned above, the first main network node and the first subnet node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD. Still taking nodeA as an example, if nodeA finds the identity information of nodeA1 in the data field, then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block; nodeB～nodeD are processed in a similar way , which will not be repeated here.

In addition to configuration information, the execution result of the contract can include the genesis block. In other words, in addition to including configuration information in the data field, you can also directly generate a genesis block containing configuration information in the process of executing the contract call, so that the genesis block is included in the data field, then for the above nodeA ~ nodeD and In other words, the corresponding node devices 1-4 can directly obtain the genesis block from the data field through the message mechanism without generating it by themselves, which can improve the deployment efficiency of nodeA1-nodeD1.

In this specification, the transaction of establishing a blockchain subnet may not be a transaction that calls a smart contract, so that a blockchain network that does not support smart contracts can also implement the technical solution of this specification, so that on the basis of the blockchain main network Quickly create a blockchain subnet. For example, a group of network transaction type identifiers can be pre-defined, and when the transaction contains the network transaction type identifier, it indicates that the transaction is used to form a new blockchain subnet, that is, the transaction is a transaction to form a blockchain subnet. The blockchain platform code can contain relevant processing logic for building a blockchain subnet, so that when the first main network node running the blockchain platform code executes a transaction, if it finds that the transaction contains the above-mentioned networking transaction type identification, and the first main network node belongs to the node member indicated by the configuration information in the transaction, based on the above processing logic, the node device deploying the first main network node can be triggered to generate a genesis block containing the configuration information and start the first A subnetwork node, the first subnetwork node loads the genesis block to form a blockchain node in the blockchain subnetwork.

The node device pulls up a process and creates an instance in the process, and the instance runs the blockchain platform code, which is equivalent to deploying a blockchain node on the node device. For the first main network node, the node device creates the first instance in the above process, and the first instance runs the blockchain platform code to form. Similarly, for the first subnetwork node, the node device creates a second instance different from the first instance in the above process, and the second instance runs the blockchain platform code to form. When the first instance and the second instance are in the same process, because no cross-process interaction is involved, the difficulty of deploying the first subnet node can be reduced and the deployment efficiency can be improved; of course, the second instance may also be in separate nodes from the first instance In different processes on the device, this specification does not limit this. In fact, each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on any node device, and each blockchain node deployed on any node device The blocks generated by the nodes are respectively stored in different storages (such as databases) on any node device, and the storages used by each blockchain node deployed by any node device are isolated from each other.

Through the above method, a blockchain subnet can be created on the blockchain mainnet. Taking Figure 4 as an example, subnet0 originally included nodeA~nodeE, and subnet1 can be built on the basis of subnet0. This subnet1 includes nodeA1~nodeD1, and nodeA and nodeA1, nodeB and nodeB1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed in on the same node device. Similarly, subnet2 or more blockchain subnets can also be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device. And, you can use subnet1, subnet2, etc. as the blockchain main network, and further build a blockchain subnet on this basis, for example, build a blockchain subnet subnet3 on the basis of subnet1, and its process is the same as the establishment of subnet1 or subnet2 Similarly, just replace the blockchain main network with the blockchain subnet subnet1, which will not be repeated here, and finally get subnet3 including nodeA3, nodeB3 and nodeC3, so that nodeA and nodeA1, nodeA2, nodeA3, nodeB and nodeB1, nodeB2, nodeB3, nodeC and nodeC1, nodeC2, nodeC3 are respectively deployed on the same node device.

For any blockchain network established by the aforementioned method (such as the above-mentioned blockchain main network or blockchain subnet), smart contracts can be deployed on it, and the contract code of the smart contract runs in a distributed manner to form the blockchain In the virtual machines of each blockchain node of the network. In related technologies, the contract code of smart contracts is usually written by users or technicians through manual programming. Therefore, the standardization of smart contract codes is low, which is not conducive to the generation and execution of smart contracts, and limits the deployment and execution efficiency of smart contracts. .

To this end, this specification proposes a smart contract deployment method. Allows users to describe the workflow of a specific business using a workflow description language (Workflow Description Language), thereby generating task code written in this language, and compiling the task code through an automated compiler to directly generate Smart contracts that can be used for deployment, so as to describe the workflow through a unified standardized workflow description language, which improves the standardization of the generated contract code; and allows users to write task code using this language compared to directly writing contract code , and use the compiler to automatically generate the contract code according to the task code, which effectively ensures the generation efficiency of the standardized smart contract and also helps to ensure the execution efficiency of the contract. The method will be described in detail below in conjunction with the examples.

Please refer to FIG. 5, which is a flowchart of a smart contract deployment method provided by an exemplary embodiment. As shown in FIG. 5 , the method may include the following steps: Step 502 , the user determines the workflow corresponding to the service.

Users can sort out the workflow involved in a specific business through various methods such as drawing and text description, so as to determine the workflow of a specific business. The determined workflow may include multiple tasks to be performed, and the logical relationship between each task to be performed corresponds to the business logic of a specific business.

For example, there may be a dependency relationship between different tasks to be executed, that is, the tasks are executed sequentially according to the serial order of time. For example, the first task to be executed requires the execution result of the second task to be executed as an input parameter, and the first The execution task needs to be executed after the execution of the second task to be executed is completed. Alternatively, there may be no dependency relationship between different tasks to be executed, that is, the tasks may be executed simultaneously in parallel order in time, for example, there is no data discrepancy between the first task to be executed and the second task to be executed If there is mutual demand, the second task to be executed can be executed while the first task to be executed is executed; of course, the second task to be executed can also be executed after the first task to be executed is completed, or the second task to be executed can be executed The first to-be-executed task is executed after completion, and the embodiment of this specification does not limit the specific timing relationship of each to-be-executed task in the workflow.

Step 504, the user uses the workflow description language to write the task code describing the workflow.

After determining the above workflow, the user can directly use the workflow description language to write task codes according to the workflow. Specifically, the above-mentioned task codes can be written using workflow description languages such as open source OpenWDL. Of course, the task codes can also be written using BPMN language (Business Process Model and Notation, business process modeling and labeling). The embodiment of this manual The specific form of the workflow description language is not limited. Because the above-mentioned OpenWDL or BPMN language is simpler and easier to understand than C++, Bitcoin Script, solidity and other smart contract programming languages, and it is easier to accurately describe the workflow at the business level, so users only need to pay attention to the overall business of the specific business The process is enough, and there is no need to worry about the underlying implementation of specific business in the smart contract, so using this language to write task codes can help reduce the user's use threshold and improve the generation efficiency of smart contracts.

Step 506, the blockchain platform invokes the compiler to generate a smart contract according to the task code.

Users can write the above task code in the client corresponding to the blockchain node, so that after the writing is completed, the client can automatically upload the task code to the blockchain platform to generate the contract code. Alternatively, users can also write task codes in offline devices, and upload the completed task codes to the blockchain platform to generate contract codes. Alternatively, users can also write task codes in offline devices, and generate contract codes on the client with the completed task codes, and then deploy the contract codes to the blockchain platform through the client to complete the deployment of smart contracts. No longer. In addition, users can use text editors or code writing software with code debugging functions to write the above task codes, which is not limited in this manual.

Among them, a compiler can be deployed in the blockchain platform, and the compiler can be used to generate contract code written in a high-level language or directly generate bytecode according to the task code written in the workflow description language. Taking the workflow description language as OpenWDL and the contract code compiled in C++ language as an example, because there is no similar compiler applied to blockchain scenarios in related technologies, the compiler described in the embodiments of this manual is developed by the inventor himself Compiler for generating contract code written in C++ language based on task code written in OpenWDL language. Specifically, after receiving the task code uploaded by the client or user equipment, the blockchain platform can call the compiler to generate the contract code according to the task code, thereby generating a smart contract.

It is understandable that because the task code is written by the user for the workflow through the workflow description language, and the workflow often only focuses on the logical flow and overall framework of the business, so the task code does not contain specific business implementation methods. In the process of compiling the task code, the above-mentioned compiler can generate the contract code according to the relevant processing logic to realize the specific business in the blockchain scenario, such as expanding the underlying functions during the compilation process, etc., to ensure the normal operation of the contract code . For example, when the task code includes "read data D1 from database A1", the contract code generated by the compiler can include "access database A1", "request D1 from database A1", "receive encrypted data returned by database A1 Dog's data D1", "decrypt and verify the received data D1" and other specific implementation processes. Obviously, the above implementation processes do not require the user to write in the task code, so the user only needs to pay attention to the business logic, and the compiler generates the contract code that specifically implements the business logic during the compilation process.

Step 508, the platform deploys the smart contract to the blockchain network.

After generating the above contract code, the blockchain platform can initiate a blockchain transaction for deploying the contract code, so that each blockchain node in the blockchain network can execute the transaction in their respective nodes The corresponding smart contract is deployed (that is, the contract code is used as the contract content of the smart contract).

Obviously, the contract code generated by the above method contains the business logic of the aforementioned workflow, so when the final deployed smart contract is executed, it can realize the tasks to be executed of the aforementioned workflow, thereby completing the specific business specified by the user.

Please refer to Fig. 6, Fig. 6 is a flow chart of another smart contract deployment method provided by an exemplary embodiment, which can be applied to blockchain node instances (that is, blockchain nodes), blockchain nodes corresponding Blockchain platform, etc., the following uses the blockchain platform as an example to illustrate. As shown in Figure 6, the method may include the following steps:

Step 602, acquiring the task code generated by describing the workflow using the workflow description language.

As mentioned above, the blockchain platform can receive the task code obtained by the user to describe the workflow using the workflow description language (that is, written in the workflow description language), and the task code can be used to describe the tasks contained in the workflow. Various tasks to be performed and their interrelationships, etc. The above task codes can be manually written by the user, or, in order to reduce the user's code writing workload and further reduce the user's threshold for deploying contract codes, the blockchain platform can provide users with predefined task templates, so that users can The task template can be configured by dragging, pulling, and dropping in the task interface displayed on the terminal. Of course, the configuration parameters for the task template can also be entered in the parameter configuration interface of the task template. Furthermore, the blockchain platform can automatically generate task codes based on configuration information such as the connection relationship between the above task templates, the timing relationship, and the configuration parameters of each task template. It can be seen that users only need to configure simple parameters for predefined task templates according to specific businesses, and the blockchain platform can automatically generate task codes, thereby realizing one-click generation of task codes, and even one-click generation and deployment of smart contracts , greatly reducing the user's contract deployment threshold and improving deployment efficiency.

In step 604, the task code is compiled by a compiler to generate a contract code for representing the workflow.

As mentioned above, a compiler in the form of a functional plug-in can be deployed in the blockchain platform, so the platform can use the compiler to compile the task code to obtain the contract code. Among them, the blockchain platform can compile the above task codes into contract codes written in high-level languages such as C++, Java, and Python. In fact, during the execution of the smart contract, the contract code written in the above-mentioned high-level language needs to be further compiled into bytecode before it can be executed. Therefore, in order to speed up the execution of the smart contract and reduce the compilation time in the execution process, the block The chain platform can also directly compile the task code into bytecode and use the bytecode as the contract code. Of course, considering the poor readability of the bytecode, in order to ensure that the user is fully aware of the contract code during the generation of the smart contract, the blockchain platform can also compile the task code into a high-level language Code, and then further compile the code written in the high-level language into bytecode, and use the bytecode as the contract code. At this time, the blockchain platform can provide the code written in the above-mentioned high-level language to the user (for example, send it to the client for display), so that the user can modify or adjust the task code by viewing the code, and improve the flexibility of generating smart contracts. sex.

Step 606, sending a block chain transaction for deploying the contract code to the block chain network, so as to deploy the corresponding smart contract in the block chain network, and the smart contract is used to be called according to the The business logic defined by each task node in the workflow assigns tasks to be executed to the node members participating in the blockchain network.

Taking the blockchain network shown in Figure 4 as an example, in the blockchain main network subnet0, the node devices where each blockchain node in the network is located belong to the corresponding blockchain members. For example, when subnet0 is a consortium chain, each blockchain node nodeA, nodeB, nodeC, nodeD, and nodeE in subnet0 can correspond to different consortium chain members respectively.

After the above contract code is generated, the blockchain platform can send a blockchain transaction for deploying the contract code to the blockchain network, so that each blockchain node in the blockchain network can execute the transaction (of course, if necessary At this time, the transaction can be consensused first, and then executed separately when the consensus is passed), so as to deploy the smart contract containing the above contract code to the blockchain network. Because the above contract code is generated based on the task code, and the task code is obtained by using the workflow description language to describe the workflow containing the tasks to be executed, the smart contract can be invoked according to the business logic defined by each task node in the workflow Assign tasks to be executed to the node members participating in the blockchain network, so as to complete the execution of the tasks to be executed through the execution of smart contracts, so as to realize the specific business corresponding to the business logic.

Furthermore, in the case that the above-mentioned contract code is written in a high-level language, the blockchain platform can compile the contract code into bytecode and then deploy the bytecode to reduce the waiting time for smart contract execution. Of course, in order to reduce the waiting time for users to deploy smart contracts, the blockchain platform can also deploy contract code written in a high-level language in the blockchain network, and start compiling the contract code into bytecode immediately after the deployment is completed. Therefore, the execution efficiency of smart contracts is guaranteed by pre-compiling before execution.

It can be seen that this solution allows users to use a workflow description language to describe the workflow of a specific business, thereby generating task code written in this language, and compiling the task code through an automated compiler to directly generate a contract that can be used for deployment Code, so as to describe the workflow through a unified and standardized workflow description language, which improves the standardization of the generated contract code; and compared with writing contract code directly, users are allowed to use this language to write task code and use the compiler The contract code is automatically generated according to the task code, which effectively improves the generation efficiency of the standardized smart contract, thus helping to ensure the execution efficiency of the contract.

Further, after the deployment of the above-mentioned smart contract is completed, the blockchain nodes in the blockchain network can execute the smart contract in response to the blockchain transaction. For this reason, this specification proposes another smart contract deployment method, which is applied to the blockchain nodes in the blockchain network. The method will be described in detail below in conjunction with FIG. 7 .

Step 702, in response to the received blockchain transaction for deploying the contract code, deploy the corresponding smart contract in the blockchain network; the contract code is generated by compiling the task code by the compiler, and the task code Generated by describing the workflow in the workflow description language.

Step 704, in response to the received blockchain transaction calling the smart contract, assign tasks to be executed to node members participating in the blockchain network according to the business logic defined by each task node in the workflow.

In this embodiment, the smart contracts deployed in the blockchain network can be invoked and executed by blockchain transactions issued by any blockchain node. As mentioned above, the task code is generated by describing the workflow by the workflow description language, and the contract code is generated by compiling the task code by the compiler, so the smart contract defines the workflow corresponding to each task to be executed, Wherein, there are corresponding task nodes for each task to be executed. The process of executing the smart contract is the process of sequentially executing each task to be executed defined in the workflow. The execution of the task to be executed makes the working status of the smart contract transition between each task node according to the preset order of the workflow.

As mentioned earlier, the deployed smart contracts above can be invoked by blockchain exchanges. In an embodiment, the block chain node can respond to the first transaction of calling the smart contract, and the processing progress of the workflow is before the first task node and the input parameters provided by the first transaction make the execution of the first task node When the condition is met, a task assignment event including the first task to be executed corresponding to the first task node is generated. Wherein, the above-mentioned first transaction is used to trigger the execution of the first task to be executed in the smart contract. For example, after the first transaction invokes the smart contract, the smart contract can generate a task assignment event corresponding to the first task to be executed. The task dispatching center of the blockchain platform obtains it, and assigns the first task to be executed to the corresponding executor for processing according to the event.

In an embodiment, the execution condition of the above-mentioned first task node may be that the data format of the input parameter provided by the first transaction meets the requirements. The task defined by the workflow in the smart contract may be called "contract task". Suppose the first transaction pushes the workflow to start executing contract task A, that is, the first task node is the task node A corresponding to contract task A, then the first The input parameters provided by a transaction can be the event type type in the form of a string (String), and the parameter args in the form of bytes (Bytes). Therefore, the block chain node can determine that the input parameters provided by the first transaction meet the execution conditions when judging that the above-mentioned event type and the data format of the parameters conform to the specified format of the called method. It can be seen that if the processing progress of the workflow at the current moment is ahead of the task node A, the execution condition is met as a trigger condition for the blockchain node to generate a task assignment event corresponding to the task node A. For example, when the first transaction calls the aforementioned transit method of the contract, the provided parameter ev can be

In another embodiment, the execution condition of the above-mentioned first task node may also be: the input parameter provided by the first transaction is the second pending task corresponding to the second task node before the first task node in the workflow. The execution result of the execution task. For example, when the first task to be executed is contract task B, and the second task to be executed is contract task A on which contract task B depends, the first task node is the task node B corresponding to contract task B. When , the execution result of contract task A can be used as the input parameter of contract task B, so when the input parameter provided by the first transaction is the execution result of contract task A (that is, it indicates that contract task A has been executed at the current moment), the corresponding The block chain node instance can determine that the input parameters provided by the first transaction meet the execution conditions. It can be seen that if the processing progress of the workflow at the current moment is ahead of the task node B, then the execution condition being satisfied can be used as a trigger condition for the node device to generate a task assignment event corresponding to the task node B.

Of course, the execution condition of the first task node can also include the above two at the same time, that is, the execution condition can be "the input parameter provided by the first transaction is provided by the second task node before the first task node in the workflow." The execution result of the corresponding second to-be-executed task, and the data format of the execution result meets the requirements", so as to achieve stricter management on the input parameters of any task in the workflow.

In one embodiment, the block chain platform code is deployed in the node device described in this specification, and the block chain node instance is formed locally when the node device runs the platform code, thereby forming a block in the node device In addition, the node device can also be deployed with a blockchain business code, and the node device will form a business instance locally during the process of running the business code. Among them, the blockchain node instance can be used to generate the above-mentioned task allocation event, and the business instance can be used to monitor the task allocation event and determine that the blockchain member to which the node device belongs is the executor of the first task to be executed Next, participate in the execution of the first task to be executed. It can be seen that the blockchain node that executes the smart contract can generate the above task assignment event, and the business instance in the node device where any blockchain node in the blockchain network is located can determine its location based on the event after listening to the event. Whether the blockchain member to which the node device belongs is the executor of the first task to be executed, and then participate in the execution of the first task to be executed if it is determined to be yes; of course, in the case of no, the event can be directly discarded .

In an embodiment, the blockchain node instance can include the identity information of the blockchain member of the assigned object in the task assignment event, so that the business instance deployed in the node device where any blockchain node of the blockchain network is located It can be determined that the first contract task included in the task assignment event is assigned to the first node when the task assignment event is monitored and the blockchain member to which the node device belongs is determined to be the executor of the first task to be executed The first block chain member to which the device belongs, that is, it is determined that the service instance deployed in the node device where it is located executes the first contract task. Among them, the above-mentioned identity information can be the member identification of the block chain member, or the device identification of the node device (in the case that only one block chain node in the block chain network is deployed in one node device), it can also be The node public key of the blockchain node corresponding to the blockchain member or the summary of the node public key, etc., are not limited in this manual. Alternatively, it is also possible to specify corresponding task assignment conditions for blockchain members in advance, so that any blockchain node can It is determined that the first contract task included in the task assignment event is assigned to its corresponding blockchain node member, that is, it is determined that the first contract task is executed by the business instance corresponding to the blockchain node member. In fact, in the following embodiments of this specification, any blockchain node can determine whether its corresponding blockchain node member is the executor of the first task to be executed in the above-mentioned manner. The following embodiments do not Let me repeat.

In an embodiment, there may be multiple executors for the first to-be-executed task, and at this time, the service instances corresponding to each executor may respectively execute the first to-be-executed task. Certainly, the above-mentioned first task to be executed may also include multiple subtasks, and at this time, the service instances corresponding to each executing party may also respectively execute the above-mentioned multiple subtasks.

In an embodiment, the above-mentioned first task to be performed may be in the form of various tasks such as private computing, file system access, and database access, so that the business instance may also perform the first task to be performed in various ways. For example, the service instance can call the computing resources deployed locally on the node device to execute the first task to be executed, for example, the service instance in the node device 1 can call the task unit managed by the task unit container 11 deployed locally on the node device 1 to execute the contract task A (At this point, contract task A is the first task to be executed). For another example, the service instance may also call computing resources deployed outside the node device to execute the first task to be executed, for example, the service instance in the node device 2 may call the task unit managed by the task unit container 21 locally deployed on the node device 2 and The off-chain computing resources deployed in other devices than the node device 2 cooperate to execute the contract task C (at this time, the contract task C is the first task to be executed). Of course, the business instance in node device 1 can also call multiple computing resources deployed locally on the node device to execute contract task A, or the business instance in node device 2 can also only call off-chain computing resources to execute contract task C. The description does not limit this. In program practice, appropriate computing resources can be flexibly selected to execute the first task to be executed according to actual task requirements such as task type, computing resource consumption, and time-consuming requirements, so as to realize more flexible program practice and expand the scope of the method described in this specification. Applicable scene.

In an embodiment, during the process of deploying the above-mentioned blockchain node instance and business instance, any node device can pull up multiple processes respectively, and run the above-mentioned blockchain platform code and blockchain respectively in different processes. Task code, so that the blockchain node instance and the business instance are deployed in different processes. Correspondingly, data transmission can be realized through cross-process interaction between the blockchain node instance and the business instance. In this way, it is ensured that blockchain node instances and business instances generate as little interference as possible during operation, and fault isolation between different instances is realized. Or, in order to reduce the delay that may occur during the above-mentioned cross-process interaction and ensure the task execution efficiency during the execution of the smart contract, the node device can also deploy the above-mentioned blockchain node instance and business instance in the same process. This is not limiting.

In one embodiment, any blockchain node in the blockchain network can determine whether its corresponding blockchain node member is the first task to be executed after listening to the task assignment event for the first task to be executed executor, and then in the case of determining that its corresponding block chain node member is the executor of the first task to be executed, it can create a subnetwork node instance in the node device where it is located, and communicate with other members of the first task to be executed The subnetwork node instance created by the executor forms a blockchain subnetwork. Furthermore, blockchain nodes can submit subnetwork transactions on the established blockchain subnetwork, so that their corresponding blockchain node members can execute the first task to be executed—each subnetwork node in the blockchain subnetwork will execute The transaction is thus executed by the blockchain subnetwork. Taking the scenario shown in Figure 4 as an example, assuming that smart contracts are deployed in subnet0 of the blockchain main network, nodeA, nodeB, nodeC, nodeD, and nodeE can respectively determine their own Whether it is the executor of the task to be executed corresponding to the event: If nodeA, nodeB, nodeC, and nodeD respectively determine themselves to be the executor of the task to be executed, they can create subnetwork node instances nodeA1, nodeB1, nodeC1, and nodeD1 respectively, and Set up a block chain subnet subnet1 containing the above subnet node instances, and then execute the tasks to be executed corresponding to the above task assignment events in the subnet1.

It can be seen that after each blockchain node in the blockchain network monitors the same task assignment event, each executor of the task to be executed corresponding to the task assignment event can build a blockchain subnet accordingly, and through each blockchain The mutual cooperation of nodes in this subnetwork completes the execution of tasks to be executed. Obviously, the blockchain network at this time is equivalent to the blockchain main network, and the network composed of each blockchain node is the blockchain subnet. The network ensures that the relevant data in the execution process of the blockchain node corresponding to the task assignment event will not be known by other irrelevant nodes in the blockchain main network, effectively ensuring the small-scale privacy of the data. Moreover, the execution results of the above-mentioned relevant data and tasks can be stored in the identity of the data corresponding to the blockchain subnet, without being confused with the data of the blockchain main network, which further ensures the security and privacy of the data.

A specific embodiment will be described below. For example, for a project S, its workflow includes:

Step 1: Pull data from the database of the store SSS and process it, and then output the result of this step as the output result of this step and save it on the blockchain.

Step 2: Build a blockchain subnet, and the participants of the blockchain subnet will agree on the results of the previous step.

Apparently, the above two steps may correspond to two tasks to be executed with dependencies (ie, MYTASK1 and MYTASK2 described below). Correspondingly, the task code written in OpenWDL language can be as follows:

Wherein, the above-mentioned subnet transactions may include blockchain transactions for invoking smart contracts. For example, corresponding to the above task code, the first task to be executed is the task MYTASK1 corresponding to the first step, and the subnet transaction initiated in the subnet can be a blockchain transaction that calls the contract code corresponding to the part of the task MYTASK1 in the smart contract, so that Each node in the subnet can execute this part of the contract code to complete the execution of the task MYTASK1.

Specifically, there are many ways to execute the above-mentioned subnetwork transactions. For example, the subnetwork nodes corresponding to the executor of the first task to be executed in the blockchain subnetwork may all be consensus nodes. At this time, the subnetwork transactions are executed by each subnetwork node after passing the consensus of the blockchain subnetwork. In this way, the reliability of the executed subnet transactions is guaranteed through consensus. Alternatively, when the above-mentioned first task to be executed includes multiple subtasks, the subnetwork nodes corresponding to the executor of the first task to be executed in the blockchain subnetwork may also be non-consensus nodes. After the consensus of the blockchain subnetwork, different subtasks can be performed by each subnetwork node. It can be seen that the sub-network transactions at this time do not need to go through consensus, so each sub-network node can execute their own sub-network transactions synchronously, which helps to improve the execution efficiency of blockchain transactions.

Certainly, in the above-mentioned embodiment, the block chain subnet established in response to the task assignment event can be disbanded after the block chain transaction corresponding to the task assignment event is responded to (that is, after the execution of the first task to be executed is completed), so that The established blockchain subnetwork is constructed along with the execution of the blockchain transaction, and disbanded with the execution of the transaction, thus realizing the temporary establishment of the blockchain subnetwork. Obviously, the life cycle of the blockchain subnet is the same as the life cycle of the corresponding blockchain transaction, which avoids the possible reduction in efficiency caused by the simultaneous maintenance of too many blockchain network network information by blockchain nodes.

In the foregoing multiple embodiments, the first task to be executed may include multiple subtasks, and the executor of each subtask may execute each subtask in a preset order, and the preset order may be the execution order defined in the workflow, so that Ensure that the execution sequence of each subtask corresponds to the workflow, and further ensure that the first task to be executed gets a correct execution result.

However, the smart contracts deployed in the blockchain network can be executed multiple times, so if the blockchain subnet is rebuilt every time the smart contract is executed, it will inevitably reduce the utilization rate of the blockchain subnet and cause the response of blockchain transactions Prolonged. In order to solve this problem, the blockchain subnetwork can be pre-established after the smart contract is deployed (before the smart contract is executed), that is, after any blockchain node deploys the smart contract, it will be based on the task-related information recorded in the contract ( The executor of each task to be executed) establishes a blockchain subnet corresponding to each task to be executed. The network node instance of the blockchain network and the subnetwork node instance of the blockchain subnet managed by the blockchain network are deployed on the node device corresponding to the blockchain node, so that the subnetwork node instance listens to the task assignment event And when it is determined that the corresponding subnetwork node member is the executor of the first task to be executed, the subnetwork transaction can be submitted on the blockchain subnet, so that the subnetwork node member corresponding to itself can participate in the execution of the first task to be executed.

In one embodiment, when the processing progress of the workflow at the current moment is ahead of the first task node and the input provided by the first transaction satisfies the execution conditions of the first task node, the blockchain node instance also The processing progress of the workflow can be updated after the first task node, thereby promoting the state transition of the workflow state corresponding to the smart contract.

In an embodiment, after executing the first task to be executed, the block chain node can return the execution result of the task to the first task node through the task callback method in the smart contract. Therefore, when the first transaction calls the task callback method in the smart contract, it indicates that the input parameter provided by the first transaction is the execution result of the second task to be executed; wherein, after the task callback method is called, it can be automatically triggered to advance Workflow method.

It can be seen that the above scheme allows users to use the workflow description language to describe the workflow of a specific business, thereby generating task codes written in this language, and compiling the task codes through an automated compiler to directly generate deployment-ready contract code. It can be seen that the workflow is described through a unified standardized workflow description language, which improves the standardization of the generated contract code; and compared with directly writing contract code, users are allowed to use this language to write task code, and use the compiler to compile task code according to the task code. The contract code is automatically generated, effectively ensuring the generation and execution efficiency of standardized smart contracts.

Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 8 , at the hardware level, the device includes a processor 802 , an internal bus 804 , a network interface 806 , a memory 808 and a non-volatile memory 810 , and of course may also include hardware required by other services. One or more embodiments of this specification may be implemented based on software, for example, the processor 802 reads a corresponding computer program from the non-volatile memory 810 into the memory 808 and executes it. Of course, in addition to software implementations, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.

Fig. 9 is a block diagram of a smart contract deployment device provided by an exemplary embodiment. Please refer to FIG. 9 , the device can be applied to the device shown in FIG. 8 to realize the technical solution of this specification. Wherein, the smart contract deployment device may include: a code acquisition unit 901, which acquires the task code generated by describing the workflow using a workflow description language; a code compilation unit 902, which compiles the task code through a compiler, Generate the contract code used to characterize the workflow; the transaction deployment unit 903 sends the blockchain transaction used to deploy the contract code to the blockchain network to deploy the corresponding intelligent A contract, the smart contract is used to assign tasks to be executed to the node members participating in the blockchain network according to the business logic defined by each task node in the workflow when called.

Optionally, the code obtaining unit 901 is further configured to: receive the task code sent by the client; or generate the task code according to configuration information provided by the client for a predefined task template.

Optionally, the code compiling unit 902 is also used for one of the following: compiling the task code into a contract code written in a high-level language; compiling the task code into bytecode, and compiling the bytecode As the contract code: first compile the task code into a code written in a high-level language, then further compile the code written in the high-level language into a bytecode, and use the bytecode as the contract code.

Optionally, the transaction deployment unit 903 is further configured to: compile the contract code into bytecode when the contract code is written in a high-level language, and deploy the bytecode in the blockchain network section code; or, in the case that the contract code is written in a high-level language, deploy the contract code written in the high-level language in the block chain network, and immediately start converting the contract code to Compiled to bytecode.

In addition, FIG. 10 is a block diagram of another smart contract deployment device provided by an exemplary embodiment. Please refer to FIG. 10 , the device can be applied to the device shown in FIG. 8 to realize the technical solution of this specification. Wherein, the smart contract deployment device is applied to the blockchain nodes in the blockchain network, and may include: the contract deployment unit 1001, which responds to the received blockchain transaction of deploying the contract code, in the blockchain network Deploy the corresponding smart contract; the contract code is generated by compiling the task code by the compiler, and the task code is generated by describing the workflow in the workflow description language; the contract calling unit 1002 makes the response to the received Invoke the block chain transaction of the smart contract, assign tasks to be executed to the node members participating in the block chain network according to the business logic defined by each task node in the workflow.

Optionally, it also includes: an event generating unit 1003, which makes the processing progress of the workflow be ahead of the first task node and the input parameters provided by the first transaction satisfy the execution condition of the first task node , generating a task assignment event including the first task to be executed corresponding to the first task node.

Optionally, the execution condition includes at least one of the following: the data format of the input parameter provided by the first transaction meets the requirements; the input parameter provided by the first transaction is the first task node before the first task node in the workflow. The execution result of the second to-be-executed task corresponding to the second task node.

Optionally, a block chain node instance and a service instance are deployed on the node device corresponding to the block chain node, the block chain node instance is used to generate the task assignment event, and the service instance is used to monitor Participate in the execution of the first to-be-executed task when the task assignment event occurs and the block chain member to which the node device belongs is determined to be the executor of the first to-be-executed task.

Optionally, there are multiple executors for the first to-be-executed task, and the business instances corresponding to each executor respectively execute the first to-be-executed task, or the business instances corresponding to each executor respectively execute the first to-be-executed task A task contains multiple subtasks.

Optionally, the service instance corresponding to any executor executes any task, including: the service instance invokes a local computing resource deployed on the node device where it is located to execute any task; and/or, the service instance invokes The computing resource deployed outside the node device where it is located executes any of the above tasks.

Optionally, the blockchain node instance and the service instance deployed in any node device are in different processes.

Optionally, the node device corresponding to the blockchain node is deployed with a network node instance of the blockchain network and a subnet node instance of the blockchain subnet managed by the blockchain network, the subnet When the network node instance listens to the task allocation event and determines that its corresponding subnetwork node member is the executor of the first task to be executed, it submits a subnetwork transaction on the blockchain subnetwork, so that The corresponding subnetwork node members participate in executing the first task to be executed.

Optionally, it also includes: the subnet creation unit 1004, so that when the task allocation event is monitored and the block chain node member corresponding to itself is determined to be the executor of the first task to be executed, in its own Create a subnet node instance in the node device, and form a block chain subnet with the subnet node instances created by other executors of the first to-be-executed task; the transaction submission unit 1005 makes the established block chain subnet Submit a subnetwork transaction, so that the first task to be executed is executed by its corresponding block chain node member.

Optionally, the subnet transaction includes a transaction for invoking the smart contract.

Optionally, the corresponding subnet nodes of the executor of the first to-be-executed task in the blockchain subnet are all consensus nodes, and after the subnet transaction passes the consensus of the blockchain subnet, it is accepted by each Subnetwork nodes are executed separately.

Optionally, the first to-be-executed task includes a plurality of sub-tasks, and the sub-network nodes corresponding to the executor of the first to-be-executed task in the blockchain sub-network are all non-consensus nodes, and the sub-network transaction Without going through the consensus of the blockchain subnetwork, each subnetwork node performs different subtasks respectively.

Optionally, any blockchain node determines that its corresponding blockchain node member is the executor of the first to-be-executed task, including: the task assignment event includes the The identity information of the blockchain node members; or, the task content of the first task to be executed matches the task allocation conditions corresponding to the blockchain node members corresponding to any of the blockchain nodes.

Optionally, the executor of each subtask executes each subtask according to the execution sequence defined in the workflow.

Optionally, it also includes: a progress updating unit 1006, so that when the processing progress of the workflow is before the first task node and the input parameters provided by the first transaction satisfy the execution condition of the first task node , the block chain node instance updates the processing progress of the workflow after the first task node.

Optionally, any executor of the to-be-executed task is further configured to: call a task callback method in the smart contract, and return the execution result of the to-be-executed task to the smart contract.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Combinations of any of these devices.

For the convenience of description, when describing the above devices, functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in one or more pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can 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, etc.) 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 should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

The specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The present description 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 storage devices.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. 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 Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that 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. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes 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 specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A smart contract deployment method, including:

Obtain the task code generated by using the workflow description language to describe the workflow;

compiling the task code by a compiler to generate a contract code for representing the workflow;

Send a block chain transaction for deploying the contract code to the block chain network, so as to deploy the corresponding smart contract in the block chain network, and the smart contract is used to The business logic defined by each task node assigns tasks to be executed to the node members participating in the blockchain network.
According to the method according to claim 1, obtaining the task code comprises:

receiving said task code sent by the client; or,

The task code is generated according to the configuration information provided by the client for the predefined task template.
The method according to claim 1, said compiling said task code comprises one of the following:

Compile the task code into a contract code written in a high-level language;

compiling the task code into bytecode, and using the bytecode as the contract code;

The task code is first compiled into a code written in a high-level language, and then the code written in the high-level language is further compiled into a bytecode, and the bytecode is used as the contract code.
According to the method according to claim 3, when the contract code is written in a high-level language, deploying the corresponding smart contract in the blockchain network includes:

Compile the contract code into bytecode and deploy the bytecode in the blockchain network; or,

Deploy the contract code written in the high-level language in the block chain network, and start compiling the contract code into byte code immediately after the deployment is completed.
A smart contract deployment method applied to blockchain nodes in a blockchain network, including:

In response to the received blockchain transaction of deploying the contract code, deploy the corresponding smart contract in the blockchain network; the contract code is generated by compiling the task code by the compiler, and the task code is generated by the workflow The description language is generated by describing the workflow;

In response to the received blockchain transaction invoking the smart contract, according to the business logic defined by each task node in the workflow, tasks to be executed are assigned to the node members participating in the blockchain network.
The method according to claim 5, further comprising:

When the processing progress of the workflow is before the first task node and the input parameters provided by the first transaction satisfy the execution conditions of the first task node, generate the first task node corresponding to the first task node A task assignment event that executes a task.
The method according to claim 6, the execution conditions include at least one of the following:

The data format of the input parameters provided by the first transaction meets the requirements;

The input parameter provided by the first transaction is the execution result of the second task to be executed corresponding to the second task node before the first task node in the workflow.
According to the method according to claim 6, a block chain node instance and a service instance are deployed on the node device corresponding to the block chain node, and the block chain node instance is used to generate the task assignment event, and the service instance The instance is used to participate in the execution of the first task to be executed when the task assignment event is monitored and the block chain member to which the node device is located is determined to be the executor of the first task to be executed.
According to the method according to claim 8, there are multiple executors in the first task to be executed, and the business instances corresponding to each executor respectively execute the first to-be-executed task, or the business instances corresponding to each executor respectively execute the Multiple subtasks included in the first to-be-executed task.
According to the method according to claim 8, the business instance corresponding to any executor performs any task, including:

The service instance invokes the local computing resource deployed on the node device where it is located to execute any of the tasks; and/or,

The service instance invokes computing resources deployed outside the node device where it is located to execute any of the tasks.
According to the method according to claim 8, the block chain node instance and the service instance deployed in any node device are in different processes.
According to the method according to claim 6, the node device corresponding to the blockchain node is deployed with a network node instance of the blockchain network and a subnetwork node of the blockchain subnet managed by the blockchain network Instance, when the subnetwork node instance listens to the task allocation event and determines that its corresponding subnetwork node member is the executor of the first task to be executed, it submits the subnetwork on the block chain subnetwork transaction, so that its corresponding subnetwork node members participate in executing the first task to be executed.
The method of claim 6, further comprising:

When the task allocation event is monitored and the block chain node member corresponding to itself is determined to be the executor of the first to-be-executed task, create a subnetwork node instance in the node device where it is located, and communicate with the second A subnetwork node instance created by other executors of the task to be executed to form a blockchain subnetwork;

Submitting a subnetwork transaction on the established blockchain subnet, so that its corresponding blockchain node members can execute the first task to be executed.
The method of claim 13, the subnetwork transactions include transactions for invoking the smart contracts.
According to the method according to claim 13, the subnet nodes corresponding to the executor of the first task to be executed in the block chain subnet are all consensus nodes, and the subnet transactions pass through the block chain subnet After consensus, it is executed by each subnetwork node.
According to the method according to claim 13, the first task to be executed includes a plurality of subtasks, and the subnetwork nodes corresponding to the executor of the first task to be executed in the blockchain subnetwork are all non-consensus nodes, The sub-network transactions do not go through the consensus of the block chain sub-network, and each sub-network node performs different sub-tasks respectively.
According to the method according to any one of claims 8-16, any blockchain node determines that its corresponding blockchain node member is the executor of the first task to be executed, including:

The task assignment event includes the identity information of the blockchain node member corresponding to any blockchain node; or,

The task content of the first to-be-executed task matches the task allocation conditions corresponding to the blockchain node members corresponding to any one of the blockchain nodes.
According to the method according to claim 9 or 16, the executor of each subtask respectively executes each subtask according to the execution sequence defined in the workflow.
The method according to claim 5, further comprising:

When the processing progress of the workflow is ahead of the first task node and the input provided by the first transaction makes the execution condition of the first task node satisfied, the blockchain node instance converts the workflow The processing progress of is updated after the first task node.
According to the method according to claim 5, any executor of the task to be executed is also used for:

Invoke the task callback method in the smart contract, and return the execution result of the task to be executed to the smart contract.
A smart contract deployment device, comprising:

A code acquiring unit, configured to acquire task codes generated by describing the workflow using a workflow description language;

A code compiling unit, which compiles the task code through a compiler to generate a contract code for representing the workflow;

The transaction deployment unit is configured to send a block chain transaction for deploying the contract code to the block chain network, so as to deploy the corresponding smart contract in the block chain network, and the smart contract is used to be called according to The business logic defined by each task node in the workflow assigns tasks to be executed to node members participating in the blockchain network.
A smart contract deployment device applied to blockchain nodes in a blockchain network, including:

The contract deployment unit is configured to deploy the corresponding smart contract in the blockchain network in response to the received blockchain transaction of deploying the contract code; the contract code is generated by compiling the task code by the compiler, and the The task code is generated by describing the workflow in the workflow description language;

The contract invoking unit is configured to assign the node members participating in the blockchain network to be executed according to the business logic defined by each task node in the workflow in response to the received blockchain transaction calling the smart contract. Task.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-20 by running the executable instructions.
A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1-20 are implemented.