WO2022252996A1 - 为业务流程合约调度计算服务的方法 - Google Patents

为业务流程合约调度计算服务的方法 Download PDF

Info

Publication number
WO2022252996A1
WO2022252996A1 PCT/CN2022/093809 CN2022093809W WO2022252996A1 WO 2022252996 A1 WO2022252996 A1 WO 2022252996A1 CN 2022093809 W CN2022093809 W CN 2022093809W WO 2022252996 A1 WO2022252996 A1 WO 2022252996A1
Authority
WO
WIPO (PCT)
Prior art keywords
computing
node
blockchain
contract
subnet
Prior art date
Application number
PCT/CN2022/093809
Other languages
English (en)
French (fr)
Inventor
邓福喜
谢桂鲁
赵博然
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2022252996A1 publication Critical patent/WO2022252996A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5072Grid computing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1074Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078Resource delivery mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • One or more embodiments of this specification relate to the field of terminal technologies, and in particular to a method for scheduling computing services for business process contracts.
  • Blockchain technology is built on top of transmission networks such as peer-to-peer networks.
  • Network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.
  • the embodiment of this specification provides a method for scheduling computing services for business process contracts.
  • a method for scheduling computing services for business process contracts is proposed.
  • the business process contracts are deployed on the blockchain network, and the business process contracts in the Each computing task used to realize the business process is defined, and at least one node participating in each computing task is specified; the method is applied to a scheduling process that is also running on a node device corresponding to each node, and the method includes: For at least part of the computing tasks defined in the business process contract, when it is determined that the corresponding node participates in the computing task, according to the computing type of the computing task, the one that is still running on the corresponding node device corresponding to the computing type and in the The computing service process in the occupable state is scheduled to be the computing service process occupied by the computing task; wherein, the blockchain network calls the computing service process occupied by each computing task through the scheduling process during the process of executing the business process contract process to perform the computation.
  • a device for scheduling computing services for business process contracts is proposed.
  • the business process contracts are deployed on the blockchain network, and the business process contracts are defined for implementing Each calculation task of the business process, and at least one node that participates in each calculation task is designated; the method is applied to the scheduling process that is also running on the node device corresponding to each node, and the device includes: a scheduling module, for all At least part of the computing tasks defined in the above-mentioned business process contract, in the case that the corresponding node is determined to participate in the computing task, according to the computing type of the computing task, a node that is still running on the corresponding node device that corresponds to the computing type and is in the occupable
  • the computing service process of the state is scheduled to be the computing service process occupied by the computing task; wherein, in the process of executing the business process contract, the blockchain network calls the computing service process occupied by each computing task through the scheduling process to Execute the calculation task.
  • a blockchain network is proposed, on which a business process contract is deployed, and the business process contract defines the Each computing task, and at least one node that participates in each computing task is designated; a node-independent scheduling process that also runs on the node device corresponding to each node, for at least part of the computing tasks defined in the business process contract, When it is determined that the corresponding node participates in the computing task, according to the computing type of the computing task, a computing service process that is still running on the corresponding node device corresponding to the computing type and in an available state is scheduled to be occupied by the computing task. computing service process; wherein, in the process of executing the business process contract, the blockchain network calls the computing service process occupied by each computing task through the scheduling process to execute the computing task.
  • a node-independent scheduling process is run on node devices corresponding to at least some of the nodes, and the scheduling process is used to schedule a node-independent computing service process running on the node device.
  • the scheduling process corresponding to the node participating in the computing task, according to the computing type of the computing task, an available computing service process corresponding to the computing type on the same node device A computing service process scheduled to serve the computing task.
  • the blockchain network can call the computing service process occupied by each computing task through the scheduling process to execute the computing task.
  • a node executes a business process contract, it does not need to directly execute each computing task, but at least part of the computing tasks are handed over to a computing service process independent of the node for direct execution, thereby reducing the complexity of the business process.
  • the dependence of promotion efficiency on the running status of nodes even if the nodes are running abnormally, it is not easy to delay the advancement of business processes.
  • even if a computing task executes abnormally it may not require the node to repair the abnormality, and it is not easy to affect the running status of the node.
  • 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 flowchart of a method for establishing a blockchain subnet provided by an exemplary embodiment.
  • Fig. 5 is a schematic diagram of building a blockchain subnet based on the blockchain mainnet provided by an exemplary embodiment.
  • Fig. 6 is a flow chart of another method for establishing a blockchain subnet provided by an exemplary embodiment.
  • Fig. 7 is a schematic flowchart of a method for scheduling computing services for business process contracts.
  • Fig. 8 is a schematic flowchart of a business execution method based on out-of-chain computing services.
  • Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. There are also various 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.
  • 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.
  • 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.
  • EVM Ethereum Virtual Machine
  • bytecode virtual machine code
  • 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.
  • the contract is successfully created and can be called in the subsequent process.
  • 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.
  • the smart contract makes a virtual account containing contract code and account storage (Storage) generated on the blockchain.
  • 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.
  • the value of balance may change.
  • 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.
  • FIG. 3 The schematic diagram of creating a smart contract and calling a smart contract is shown in Figure 3.
  • 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.
  • 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. 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.
  • Contract execution results can be expressed as events in receipts.
  • the message mechanism can implement message delivery through the events in the receipt to trigger the blockchain node or the node device deploying the blockchain node to perform corresponding processing.
  • the structure of an event can be, for example:
  • each event includes fields such as topic and data.
  • the blockchain node or the node device deploying the blockchain node can listen to the topic of the event, so as to perform preset processing when listening to the predefined topic, or read the relevant content from the data field of the corresponding event. And preset processing can be performed based on the read contents.
  • 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.
  • 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.
  • 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.
  • 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.
  • a blockchain network at the hardware level is usually composed of multiple member node devices. Nodes are deployed on the node devices of each member, and the nodes deployed on the node devices of each member form a blockchain network at the software level.
  • a member can have multiple node devices (i.e., device cluster), and the member can flexibly (for example, consider the performance of a single device) deploy several nodes belonging to different blockchain networks in the device cluster, and participate in different blockchains through different nodes transactions in the network.
  • a node is a concept at the software level.
  • a node can be understood as an instance of code (a process or a thread) used to implement node functions. In this way, multiple node devices that are equivalent to the same member can be deployed to implement node functions. instance.
  • the controller of the node is the consortium member (organization), and the controller of the client is the user connected to the organization. Therefore, these multiple nodes can communicate with the client through different ports (or the same default port) of the node device. communicate with the client and receive the transaction submitted by the client.
  • the nodes are included in the client, and the controller of the node is the controller of the client, that is, the user. Therefore, these multiple nodes can be included in the same client, and the user can choose a node to submit a transaction.
  • the node receives the transaction submitted by the client can refer to both the consortium chain network and the public chain network.
  • the nodes of the alliance chain network are deployed on the node devices of all alliance members (that is, node members in the alliance), which can form a blockchain network, that is, all alliance members in the area
  • the nodes of the alliance chain network are deployed on the node devices of all alliance members (that is, node members in the alliance), which can form a blockchain network, that is, all alliance members in the area
  • all transactions and related data that occur on the blockchain network can be obtained through the corresponding blockchain nodes.
  • the embodiment of this specification provides a blockchain system involving multiple members.
  • the system includes a node device of each member at the hardware level. At least one node is deployed on the node device of each member. Nodes of the same member Different nodes deployed on the device belong to different blockchain networks.
  • the system has a tree structure with the blockchain main network as the root node and each blockchain subnet as other nodes.
  • a node is a concept in the sense of blockchain, which refers to a node in a blockchain network; a node is a concept in a tree structure, which in this article refers to a blockchain network in a tree structure.
  • the blockchain main network can be considered as the highest-level blockchain network in the system, which usually consists of main network nodes deployed on the node devices of all members of the system.
  • members can be divided into initial members (members who participate in initializing the system) and subsequent members (members who join after system initialization). All initial members build a blockchain system.
  • the blockchain main network in the system is composed of the main network nodes deployed on the node devices of all initial members. Later, more subsequent members can join the blockchain system. Subsequent members'
  • the main network node can be deployed on the node device to join the main network, or no main network node can be deployed, and only one or more subnet nodes can be deployed.
  • the blockchain subnets in the system can have multiple levels.
  • the top-level blockchain subnet is the child node of the blockchain mainnet in the tree structure.
  • a blockchain subnet can also have child nodes of the next level blockchain subnet.
  • the main network node of the blockchain main network is also deployed.
  • the node device corresponding to the node of a blockchain subnet may be the node device of the subsequent member, and the node device of the subsequent member may not deploy the main network node.
  • each blockchain network in the system (whether it is the main network or the subnet) is mutually isolated from each other.
  • the blockchain network can be created by manually deploying each member on its own node device. If a member needs to deploy three different blockchain networks (one main network , two subnets), then this member needs to manually deploy the blockchain network to the node device three times. However, for members, every time they need to add a node to deploy a new blockchain network on their own node devices, they need to re-execute the manual deployment process, which is troublesome. Moreover, the small-scale transaction requirements among some members are often temporary or have a certain timeliness, so that the manually deployed new blockchain subnet will soon lose the meaning of existence due to the disappearance of the demand, and the block will be cancelled. The chain subnet requires members to manually operate the node devices, which adds to the trouble.
  • another method for creating a blockchain network in the system is proposed. Based on the blockchain main network initially established in the system, a blockchain subnet is formed on the basis of the blockchain main network.
  • the blockchain main network accepts the subnet creation transaction and processes the subnet creation transaction based on the deployed contract, triggering the subnet creation event. After each main network node listens to the subnet creation event, if it determines its corresponding node Members of the device participate in the subnet, and create an instance as a node of the created subnet according to the configuration information carried in the subnet creation transaction.
  • Each blockchain subnet can also further accept subnet creation transactions and process subnet creation transactions based on deployed contracts, triggering subnet creation events, and each subnet node in the blockchain subnet listens to After the subnet creation event, if it is determined that the member of the node device corresponding to itself participates in the next-level subnet, an instance is created as a node of the further created next-level subnet according to the configuration information carried in the subnet creation transaction.
  • the blockchain network that created the blockchain subnet is the parent node of the blockchain subnet in the tree structure.
  • the blockchain subnet of the child nodes of the parent node is not necessarily created by the parent node, but it can still be managed by the parent node (that is, the child node is recorded in the blockchain network of the parent node The network identification and address information of the blockchain subnet of the point).
  • any blockchain subnetwork is created and managed by the blockchain network corresponding to its parent node.
  • members usually only need to complete a manual deployment of the main network node on their own node devices, and subsequent main network nodes on the node devices of some members can create new instances as the next-level subnet nodes.
  • Nodes of a certain blockchain subnet on the node devices of some members can further create new instances as lower-level subnet nodes.
  • the node devices of some subsequent members can still join the system after the blockchain subnet is deployed, which means that the blockchain subnet is not created by any original blockchain network in the system, but It is a blockchain subnet directly added to the system from the outside.
  • This kind of blockchain subnet can still be added to the tree structure and become a node, but the blockchain subnet of this node is corresponding to its parent node. Managed (rather than created) by the blockchain network.
  • any blockchain subnet is either created and managed by the blockchain network of the parent node, or directly added to the tree structure from the outside, and is determined by the parent node's zone. Managed by the blockchain network.
  • the address information of any blockchain subnet that is, the address information of each node included, such as IP address and port number
  • IP address and port number can only be exposed to the blockchain network of its parent node, and the Each node in the blockchain network of nodes records. In this way, the privacy of the subnet can be guaranteed to the greatest extent and the risk of network attacks can be reduced.
  • node members in the following specifically refer to members; node devices refer to devices controlled by members, which is a concept at the hardware level; nodes refer to node instances (processes or threads running on node devices), deployed on node devices, and are at the software level the concept of.
  • FIG. 4 is a flow chart of a method for establishing a blockchain subnet provided by an exemplary embodiment.
  • the method may include the following steps: step 402, each block chain node in the block chain main network respectively obtains a transaction for forming a block chain subnet, and the transaction includes the configuration information of the block chain subnet , the configuration information includes identity information of node members participating in forming the blockchain subnet.
  • 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.
  • 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.
  • the blockchain main network is subnet0
  • the blockchain nodes contained in subnet0 are nodeA, nodeB, nodeC, nodeD, and nodeE.
  • the node members corresponding to nodeA, nodeB, nodeC and nodeD respectively want to form a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate transactions to form a blockchain subnet, then nodeA can initiate the above-mentioned building blocks to subnet0 Chain subnet transactions; if nodeE is an administrator and only administrators are allowed to initiate the transaction of establishing a blockchain subnet, then nodeA ⁇ nodeD need to make a request to nodeE, so that nodeE initiates the above transaction of establishing a blockchain subnet to subnet0; if nodeE If you are an administrator but allow ordinary users to initiate transactions to establish blockchain subnets, then nodeA ⁇ nodeE can initiate the above transactions to subnet0 to establish blockchain subnets.
  • the node members corresponding to the blockchain nodes that initiate the transaction of establishing a blockchain subnet do not necessarily participate in the established blockchain subnet, for example, although nodeA, nodeB, nodeC and nodeD Corresponding node members build a blockchain subnet, but nodeE can initiate the above-mentioned transaction of building a blockchain subnet to subnet0, and nodeA ⁇ nodeD do not necessarily initiate the transaction of building a blockchain subnet.
  • the blockchain main network in this specification can be the underlying blockchain network, that is, the blockchain main network is not a blockchain subnet formed on the basis of other blockchain networks, such as the subnet0 can be regarded as the blockchain mainnet belonging to the underlying blockchain network type.
  • the blockchain main network in this specification can be a subnet of other blockchain networks.
  • subnet1 can be considered as It is the blockchain main network corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnet created on subnet0. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.
  • Step 404 each blockchain node in the blockchain main network executes the transaction to reveal the configuration information.
  • Step 406 when the configuration information includes the identity information of the node member corresponding to the first blockchain node, the node device deploying the first blockchain node starts the The second blockchain node of the blockchain subnet.
  • the consensus nodes in the blockchain main network will conduct consensus, and after the consensus is passed, each blockchain node will execute the transaction to complete the block The formation of the chain subnet.
  • the consensus process depends on the consensus mechanism adopted, such as any consensus mechanism mentioned above, which is not limited in this article.
  • 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 the node members participating in the establishment of the blockchain subnet in the configuration information, it is possible to specify which node members the established blockchain subnet corresponds to.
  • the identity information of a node member may include a public key, or other information capable of characterizing the identity of a node member such as a node ID, which is not limited in this specification.
  • a 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, and the public key can also be used to represent the identity of the node member corresponding to the blockchain node.
  • the public keys of the blockchain nodes corresponding to these node members on the blockchain main network can be added to the above-mentioned transaction of establishing a blockchain subnet as the above-mentioned nodes. Member's identity information.
  • the above-mentioned public-private key pair can be used in the process of signature verification.
  • nodeA1 in subnet1 uses its own private key to sign the message, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key of nodeA1 Signature verification is performed on the received message to confirm that the message received by itself is indeed from nodeA1 and has not been tampered with.
  • the first block chain node may be a block chain node corresponding to a node member indicated by the configuration information on the block chain main network.
  • the node device used to deploy the first blockchain node needs to generate a second blockchain node, and The second blockchain node participates in the formation of a blockchain subnet.
  • the first blockchain node and the second blockchain node correspond to the same node member, for example, in the consortium chain scenario, they correspond to the same consortium chain member, but the first blockchain node belongs to the blockchain main network and the second zone
  • the blockchain node belongs to the blockchain subnet, so that the node 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 blockchain node and the blocks generated by the second blockchain node are respectively stored in different storages on the node device (the storage used can be a database, for example), realizing
  • the storage used by the first blockchain node and the second blockchain node is isolated from each other, so the data generated by the blockchain subnet will only be synchronized between the blockchain nodes in the blockchain subnet, It makes the node members who only participate in the blockchain main network unable to obtain the data generated on the blockchain subnet, realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies
  • the first blockchain node and the second blockchain node are logically divided blockchain nodes, and from the perspective of physical equipment, it is equivalent to the deployment of the first blockchain node and the second blockchain node
  • the node device of the chain node participates in both the blockchain main network and the blockchain subnet. 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 blockchain node and the second blockchain node can use exactly the same public key, the two should still be considered as different blockchain nodes.
  • nodeA in subnet0 is equivalent to the first blockchain node
  • the node device deploying the nodeA generates nodeA1 belonging to subnet1, which is equivalent to the second blockchain node. It can be seen that since the identity systems are independent of each other, even if the public key used by the second blockchain node is different from that of the first blockchain node, it will not affect the implementation of the scheme of this specification.
  • the node members participating in the blockchain subnet are not necessarily only part of the node members participating in the blockchain main network.
  • the node members participating in the blockchain subnet can be completely consistent with the node members participating in the blockchain main network.
  • all node 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.
  • the two types of The business data generated by the business are isolated from each other.
  • 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 specification.
  • 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 main network is that since the first blockchain node has already been deployed on the node device that generates the second blockchain node, the first blockchain node can be The used blockchain platform code is reused on the second blockchain node, which eliminates the repeated deployment of the blockchain platform code and greatly improves the efficiency of the formation of the blockchain subnet.
  • the second blockchain node can reuse the attribute configuration adopted on the first blockchain node; if the configuration information includes the attribute configuration for the blockchain platform code Attribute configuration, the second blockchain node can adopt this attribute configuration, so that the attribute configuration adopted by the second blockchain node is not limited to the attribute configuration of the first blockchain node, and has nothing to do with the first blockchain 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.
  • the invoked contract can be the aforementioned genesis contract or system contract
  • the invoked method can be a method for building a blockchain subnet
  • the incoming parameters can include the above-mentioned configuration information.
  • the transaction may contain the following information:
  • the from field is the information of the initiator of the transaction.
  • Administrator indicates that the initiator is an administrator; the to field is the address of the called smart contract.
  • 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.
  • 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.
  • genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.
  • nodeA ⁇ nodeE 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, and the receipt 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.
  • nodeA ⁇ nodeE or the node devices 1 ⁇ 5 deploying nodeA ⁇ nodeE can listen to the topic contained in each event in the generated receipt, and can determine whether to listen to and execute the AddSubnet() method when the topic containing the keyword subnet is monitored Related events, that is, networking events.
  • the event in the receipt is as follows:
  • the content of the data field may include, for example:
  • 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. It can be determined 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.
  • a predefined new network identifier which indicates that the corresponding networking event is used to form a new blockchain subnet.
  • the above subnet1 can be replaced with newsubnet, which is a predefined new network identifier.
  • 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 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.
  • the above data field also contains the identity information of each node member participating in the formation of the blockchain subnet.
  • the node device deploying the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event contains the identity information of the node member corresponding to the first blockchain node , the configuration information or genesis block included in the networking event is obtained by the node device deploying the first blockchain node.
  • the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member, trigger the deployment of the first blockchain node.
  • a node device of a blockchain node acquires the configuration information or the genesis block included in the networking event.
  • node devices can listen for receipts directly. Assuming that nodeA ⁇ nodeE are respectively deployed on node devices 1 ⁇ 5, and node devices 1 ⁇ 5 can monitor the receipts generated by nodeA ⁇ nodeE respectively, then when it is detected that subnet1 is a blockchain subnet that needs to be newly established, node device 1 ⁇ 5 will further identify the identity information of the node members contained in the data field to determine its own processing method.
  • node device 1 Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as nodeA's public key, IP address, and port number, then node device 1 obtains configuration information from the data field based on the above message mechanism , generate a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and the nodeA1 will load the generated genesis block, thus becoming a subnet node of subnet1; similarly, node device 2 can generate nodeB1, node device 3 can generate nodeC1, and node device 4 can generate nodeD1. And, node device 5 will find that the identity information contained in the data field does not match itself, then the node device 5 will not generate a genesis block according to the configuration information in the data field, nor will it generate a blockchain node in subnet1.
  • identity information such as nodeA's public key, IP address, and port number
  • the blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform related processing according to the monitoring results.
  • 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.
  • 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.
  • nodeA will Trigger node device 1 so that node device 1 generates a genesis block containing the configuration information when it obtains configuration information from the data field based on the above-mentioned message mechanism, and node device 1 will deploy nodeA1 locally, and nodeA1 will load the generated Genesis block, thus becoming a subnet node of 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.
  • 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 Blockchain nodes in .
  • the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD.
  • nodeA and node device 1 may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD. Still take nodeA and node device 1 as an example: if node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and nodeA1 loads the genesis block; or, if nodeA is in the data field If the identity information of nodeA1 is found in , then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block. The processing methods of other blockchain nodes or node devices are similar and will not be repeated here.
  • the execution result of the contract can include the genesis block.
  • 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.
  • 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.
  • 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 blockchain node running the blockchain platform code executes a transaction, if it finds that the transaction contains the above-mentioned networking
  • the transaction type is identified, and the identity information of the node members corresponding to the first blockchain node is included in the configuration information in the transaction.
  • the node device deploying the first blockchain node can be triggered to generate The genesis block of the information and start the second blockchain node, and the second blockchain node loads the genesis block to form a blockchain node in the blockchain subnet.
  • the node device implements the deployment of a blockchain node on the node device by creating an instance of running the blockchain platform code in the process.
  • the node device For the first blockchain node, it is formed by the node device creating and running the first instance of the blockchain platform code in the above process.
  • the second blockchain node it is formed by the node device creating and running the second instance of the blockchain platform code in the above process.
  • the node device can first create the first instance in the process to form the first blockchain node in the blockchain main network; In the above process, a second instance is created, which is different from the above-mentioned first instance, and the second instance forms a second blockchain node in the blockchain subnet.
  • the second instance may also be in different processes on the node device from the first instance, which is not limited in this description; for example, the node device may create the first instance in the first process to form the blockchain master The first block chain node in the network; and when the node member corresponding to the node device wants to participate in the formation of a block chain subnet, it can start a second process different from the first process, and create a second process in the second process Instance, the second instance is different from the above first instance, and the second instance forms the second blockchain node in the blockchain subnet.
  • a blockchain subnet can be created on the blockchain mainnet.
  • subnet0 originally included nodeA ⁇ nodeE
  • 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.
  • subnet2 or more blockchain subnets can also be formed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA is connected to nodeA1, nodeA2, nodeB is connected to nodeB1, nodeB2, nodeC is connected to nodeC1, nodeC2, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device.
  • subnet1, subnet2, etc. can be used as the new blockchain main network, and a blockchain subnet can be further formed on this basis. The process is similar to the formation of subnet1 or subnet2, and will not be repeated here.
  • Fig. 6 is a flow chart of another method for establishing a blockchain subnet provided by an exemplary embodiment.
  • the method may include the following steps: step 602, the first blockchain node in the blockchain main network obtains a transaction for forming a blockchain subnet, and the transaction includes the configuration of the blockchain subnet Information, the configuration information includes the identity information of the node members participating in the formation of the block chain subnet.
  • Step 604 the first blockchain node executes the transaction to reveal the configuration information.
  • Step 606 when the configuration information includes the identity information of the node member corresponding to the first blockchain node, the node device deploying the first blockchain node starts the block belonging to the block based on the genesis block containing the configuration information The second blockchain node of the chain subnet.
  • the transaction of forming a blockchain subnet includes the transaction of calling a contract.
  • the contracts include genesis contracts or system contracts.
  • the execution result of the contract includes the configuration information, and the node device deploying the first blockchain node obtains the configuration information through a message mechanism, and generates the genesis block according to the obtained configuration information; or , the execution result of the contract includes the genesis block, and the node device deploying the first blockchain node obtains the genesis block through a message mechanism.
  • the receipt generated after the execution of the contract contains networking events related to the establishment of a new blockchain subnet; the node device deploying the first blockchain node obtains the configuration information or
  • the genesis block includes: the receipt generated by the first blockchain node monitoring, and when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member Next, trigger the node device deploying the first blockchain node to obtain the configuration information or the genesis block included in the networking event; or, deploy the node device deploying the first blockchain node to listen to the generated receipt, and When the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member, obtain the configuration information or the genesis block included in the networking event .
  • the networking event includes: an event in which the subject name in the receipt contains a predefined networking event identifier.
  • the content of the networking event contains the following identification, it indicates that the networking event is related to the establishment of a new blockchain subnet: the network identification of the blockchain subnet that is expected to be established, and the network identification is different from the existing A blockchain subnet; or, a predefined new network identifier, which indicates that the networking event is used to form a new blockchain subnet.
  • the transaction includes a networking transaction type identifier, and the networking transaction type identifier indicates that the transaction is used to form a new blockchain subnet.
  • the transaction of establishing a blockchain subnet is initiated by the administrator of the blockchain main network; or, the transaction of establishing a blockchain subnet is initiated by an ordinary user of the blockchain main network .
  • the configuration information also includes at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, and the attribute configuration for the blockchain platform code.
  • the administrator of the blockchain main network and the blockchain subnet may be the same or different.
  • the attribute configuration for the blockchain platform code includes at least one of the following: code version number, whether consensus is required, consensus algorithm type, and block size.
  • the node device starting the second blockchain node includes: the node device creates a second instance of running the blockchain platform code, and the second instance is different from the node device running the blockchain node.
  • the platform code corresponds to the first instance of the first blockchain node.
  • the block generated by the first block chain node and the block generated by the second block chain node are respectively stored in different storages on the node device.
  • the storage used by the first blockchain node and the second blockchain node are isolated from each other.
  • the store is a database.
  • the blockchain main network is the underlying blockchain network; or, the blockchain main network is a subnet of other blockchain networks.
  • a method for scheduling computing services for business process contracts is provided.
  • This method is usually implemented in a blockchain network, and the blockchain network can be a common blockchain network, or the main network or subnet in the aforementioned blockchain system.
  • Fig. 7 is a schematic flowchart of a method for scheduling computing services for a business process contract, including the following steps: S700: For at least part of the computing tasks defined in the business process contract, when it is determined that the corresponding node participates in the computing task, According to the computing type of the computing task, a computing service process corresponding to the computing type and in an available state running on the corresponding node device is scheduled as the computing service process occupied by the computing task.
  • the node device described in this article can be a single device or a device cluster.
  • the blockchain network described in this article can be a public chain network or an alliance chain network.
  • the business process contract is deployed on the blockchain network, and each computing task used to realize the business process is defined in the business process contract, and at least one node participating in each computing task is specified.
  • a business process contract is a smart contract used to implement a certain business process in a blockchain network.
  • several computing tasks are usually involved. According to the actual situation, not all nodes will participate in a certain computing task.
  • the nodes participating in each computing task may be all nodes of the blockchain network. It may also be some nodes of the blockchain network.
  • the computing tasks in the business process contract can be relatively independent, that is, the input of each computing task does not depend on the output of other computing tasks.
  • the calculation tasks defined in the business process contract form a directed graph structure, and each node in the graph structure corresponds to each calculation task one by one.
  • each computing task if the computing task has an incoming edge, the computing output of other computing tasks connected to the incoming edge is the input of the computing task; if the computing task has no incoming edge, the computing task does not need to be input Or the input is specified by the transaction; if the computing task has an outgoing edge, then the input of other computing tasks connected to the outgoing edge is the output of the computing task.
  • the node device corresponding to each node in the blockchain network usually runs a scheduling process independent of the node, and the scheduling process is used to schedule the computing service process.
  • the so-called computing service process refers to a process that provides computing services for computing tasks.
  • the computing service process itself has computing capabilities and is independent of nodes.
  • computing function codes corresponding to different computing types are deployed on the node devices corresponding to each node.
  • a computing service is created based on the computing function code corresponding to the computing type process.
  • Both the scheduling process and the computing service process are out-of-chain processes and do not depend on the running status of the nodes.
  • the calculation types of the computing function codes deployed on the node devices of different members of the blockchain network may be inconsistent, which may depend on the data sources that different members can connect to and the computing capabilities of different members.
  • the calculation type of calculation function code used to calculate credit risk can usually be deployed on the node equipment of financial institutions
  • the calculation type of calculation type used to calculate logistics routes can usually be deployed on the node equipment of logistics institutions. Calculate function code.
  • computing service processes of the same computing type can be created on the node device of the same member.
  • the functions of computing service processes of the same computing type may not be exactly the same. This is because, in practical applications, some computing service processes can provide general-purpose computing capabilities, and such computing service processes can directly perform computing tasks involving general computing; while some computing service processes can provide computing services for specific business scenarios. Capability, which is equivalent to the combination of business scenarios and general computing capabilities, and the types of computing service processes are usually determined according to general computing capabilities, so it may appear that multiple computing service processes of the same computing type deployed on the same node device target Different business scenarios have different capabilities. That is to say, different computing service processes corresponding to the same computing type are created based on the computing function code corresponding to the computing type and combined with different business scenario configurations, and are used to perform computing tasks in different business scenarios.
  • one or more business process contracts can be deployed in the blockchain network, and different business process contracts target different business scenarios. Therefore, even the same type of computing code can also integrate the Business scenario configuration, creating different computing service processes that serve different business process contracts.
  • the creation timing of the computing service process there are mainly the following situations: 1.
  • the business process contract before deploying the business process contract in the blockchain network, it is pre-deployed based on the node device corresponding to each node.
  • Computing function codes of several computing types create (also means starting) computing service processes of several computing types.
  • the scheduling process will schedule the computing services that have already been running, and assign the occupied computing service processes to at least part of the computing tasks in the business process contract.
  • "Occupation” here means that the computing service process is dedicated to providing computing services for computing tasks. It can be set that after a computing service process is occupied by a computing task, other computing tasks can no longer occupy the computing service process.
  • the occupied computing service process is in the occupyable state and can be regarded as idle. It can also be set that N (greater than 1) computing tasks can occupy the same computing service process. In this way, as long as the number of computing tasks occupying the computing service process does not reach N at the same time, the computing service is in an occupyable state.
  • the scheduling process can create calculations that serve the business process contract based on the content of the business process contract and the calculation function codes of each calculation type. service process.
  • the scheduling process can determine whether at least one computing service process corresponding to the computing type and in an available state is running on the corresponding node device; if the judgment result is yes, one of the computing service processes is scheduled It is the computing service process occupied by the computing task; if the judgment result is no, then in the case of meeting the device restriction conditions, based on the basic computing function code corresponding to the computing type deployed on the corresponding node device, create a corresponding to the computing type 1.
  • the computing service process is in the occupable state, which can be understood as: the computing service process is not occupied by any computing task; or, the computing service process is not occupied by N computing tasks at the same time, and N is the number of computing tasks that can occupy the computing service process maximum value.
  • the device restriction condition may be: the number of computing service processes running on the corresponding node device does not exceed the upper limit; the upper limit is determined according to the performance level of the corresponding node device.
  • a computing service process for a certain computing task when creating a computing service process for a certain computing task, if the computing task specifies a business scenario configuration, on the basis of the computing function code corresponding to the computing type deployed on the corresponding node device, combined with the specified Business scenario configuration, create a computing service process corresponding to the computing type and in the occupancy state; if the computing task does not specify a business scenario configuration, based on the basic computing function code corresponding to the computing type deployed on the corresponding node device, create A computing service process that corresponds to the computing type and is in an available state.
  • the computing service process can be temporarily scheduled for at least part of the computing tasks in the business process contract. That is, for any computing task, the computing service process occupied by the computing task is created after the business process contract is invoked by the business transaction. After the business transaction processing is completed, the occupation relationship of the business process contract on these computing service processes is released. In this way, the computing service process resources on the node device can be fully utilized.
  • the scheduling process can temporarily schedule a computing service process for the computing task whenever a computing task in the business process contract is to be executed. After the computing task is executed, the computing task is released. Occupancy of the computing service process. That is, for each computing task defined in the business process contract, the scheduling process corresponding to the node participating in the computing task, after obtaining the computing result returned by the computing service process occupied by the computing task, releases the computing task for the computing Occupancy state of the service process. In this way, the utilization efficiency of computing service process resources on the node device can be further improved.
  • each node participating in the computing task corresponds to a computing service process occupied by the computing task, and implements the computing task in a cooperative manner.
  • the collaboration method here may specifically be a multi-party secure computing method.
  • the members corresponding to each node participating in the same computing task may need to contribute their own collected data to participate in the calculation, but for the sake of data security, the members corresponding to each node participating in the same computing task need to be in the data out of the domain Under the premise of , use the computing service processes of the same computing type deployed on the respective node devices to cooperate with each other to complete the computing task.
  • the above-mentioned cooperation manner may also be other manners that require the cooperation and participation of multiple parties.
  • Fig. 8 is a schematic flowchart of a business execution method based on out-of-chain computing services provided in this specification, including the following steps.
  • Each node in the blockchain network acquires a business transaction calling the business process contract.
  • step S800 for at least part of the computing tasks (in each computing task) defined in the business process contract, the node devices running the nodes participating in the computing tasks also run: A computing service process and a scheduling process for scheduling the computing service process.
  • Business transactions usually specify business parameters as inputs to business process contracts.
  • Each node in the blockchain network executes the business process contract according to the business transaction: for at least part of the computing tasks defined in the business process contract, if it is determined that the start condition of the computing task is met, then Trigger a request event for this compute task.
  • the "at least part of the computing tasks” here can be all or part of the computing tasks in the business process contract.
  • step S802 it is for each computing task in at least some of the computing tasks.
  • the process of nodes executing the business process contract according to the transaction is the process of executing each calculation task in the business process contract according to the transaction. For a computing task that at least partially occupies the off-chain computing service process, once the node judges that the start condition of the computing task is met, it will trigger a request event for the computing task based on the event message mechanism of the contract.
  • the start condition of the calculation task can be specified according to actual needs.
  • the computing tasks in the business process contract can logically form the directed graph structure described above, the start condition of any computing task can be that every other computing task connected to the incoming edge of the computing task The tasks are all done. If the computing task requires input, the message for the request event of the computing task includes the input of the computing task. If it is determined that the start condition of the computing task is not satisfied, the node will not trigger a request event for the computing task.
  • the scheduling process corresponding to the node that does not participate in the computing task after listening to the request event, it may not process the message of the request event, and discard the message of the request event.
  • the computing service processes occupied by the computing task distributed on different node devices can execute the computing task in a cooperative manner.
  • the calculation result transaction can bring the calculation result into the business process contract, so as to advance the business process to the next calculation task.
  • this manual provides a method for creating a blockchain subnet, which is used to enable users who do not have administrator rights to initiate a blockchain subnet.
  • the method includes: 1. Each main network node separately obtains the Subnet creation transaction.
  • the network governance contract and subnet management contract can be deployed on each main network node.
  • the governance contract of this network refers to the smart contract used to govern various matters that occur in this network.
  • the "network” here refers to the blockchain network itself where the smart contract is deployed.
  • any blockchain subnet can also deploy the local network governance contract to govern various matters that occur in the blockchain subnet.
  • governance here can include the governance of the behavior of creating subnets on the local network, specifically involving the voting mechanism for the creation of subnets on the local network.
  • votes can also be made on the addition and deletion of nodes in the network, the deployment of contracts in the network, and the update of deployed contracts in the network.
  • the subnet management contract refers to the smart contract used to manage the subnet of the network.
  • the management here may include creating a lower-level subnet, and may also include closing a lower-level subnet, adding nodes to a lower-level subnet, and deleting nodes from a lower-level subnet.
  • Users without administrator privileges can construct a subnet creation transaction through their own client and submit it to the main network.
  • the subnet creation transaction specifies the subnet configuration information.
  • the subnet configuration information includes identity information of members participating in the subnet, so as to instruct the main network on which member node devices should create new subnet nodes to form a subnet.
  • the subnet creation transaction also needs to specify the called contract as the local network governance contract deployed in the main network, so that the local network governance contract triggers the voting mechanism for the creation of the subnet.
  • Each main network node executes the governance contract of this network: triggers a voting event for creating a transaction on this subnet.
  • each voting client client judges whether to allow the subnet to create a transaction, and based on the judgment result, submits a voting transaction calling the governance contract of this network to the main network.
  • Each main network node continues to execute the local network governance contract: according to the received voting transactions, when the vote is confirmed to pass, the subnet management contract is invoked.
  • Smart contracts usually support the event mechanism, providing the ability for smart contracts in the chain to interact with outside the chain.
  • Events in the blockchain network can be monitored outside the blockchain network, and transactions invoking smart contracts can be submitted to the blockchain network in response to the monitored events, so as to achieve the purpose of providing parameters to the smart contract in response to the needs of the smart contract.
  • each main network node will trigger a voting event for the subnet creation transaction.
  • the voting event message usually contains the subnet configuration information specified by the subnet creation transaction.
  • Clients of each voting party can monitor the news of the voting event, and judge whether to allow the subnet to create transactions according to the subnet configuration information of the subnet to be created.
  • each voting party can be each user with administrator authority, and the administrator user can be the member himself or some other user authorized by the member.
  • each voting party may include the following situations: all members of the system; or, some members of the system; or, some members of the system and at least one non-member; or, all all members of the system and at least one non-member; or, a plurality of non-members.
  • the method for the voter’s client to determine whether to allow the subnet to create a transaction can be specifically to display the corresponding subnet configuration information to the voter and receive the instruction (agree or disagree) input by the voter; it can also be based on the preset Judgment rules to determine whether to allow.
  • Each voting client encapsulates the judgment result into a voting transaction and submits the voting transaction to the main network. Voting transactions also need to call the governance contract of this network.
  • each main network node Based on the process of executing the governance contract of this network, each main network node receives the voting transaction submitted by the client of each voting party, and counts the voting results.
  • the method of calling is to call the subnet management contract through the local network governance contract, and pass the subnet configuration information to the subnet governance contract through the inter-contract interface, so that the subnet can be created through the subnet management contract.
  • the main network node on the node device of each member participating in the subnet deploys the subnet node after listening to the subnet creation event.
  • the main network node In the process of executing the called subnet management contract, the main network node continues to use the event mechanism to trigger the subnet creation event, and the message of the event contains the subnet configuration information.
  • Each main network node listens to the subnet creation event, and can determine whether the subnet configuration information contains the identity information of the corresponding member of the device. If it does not contain it, no processing is required. If it is included, the subnet node is deployed on the device.
  • the main network node on the node device of each member participating in the subnet when deploying the subnet node, can write the subnet configuration information into the genesis block of the block chain maintained by the subnet node middle.
  • the subnet configuration information specified by the subnet creation transaction may also include contract pre-registration information; the contract pre-registration information includes one or more business process contracts that are allowed to be deployed in the created subnet plaintext or contract hash. If the contract hash is included in the pre-registration information, the user will not expose the plaintext of the contract to the main network, but only to the created subnet.
  • the contract pre-registration information may also include contract identifiers of one or more business process contracts that are allowed to be deployed in the created subnet.
  • the contract pre-registration information may also include a business process profile corresponding to one or more business process contracts that are allowed to be deployed in the created subnet.
  • the way to deploy business process contracts to the subnet can be: each subnet node in the created blockchain subnet obtains business Process contract deployment transaction; verify whether the contract hash of the business process contract specified by the business process contract deployment transaction is recorded in the contract pre-registration information in the genesis block; if so, deploy the business process specified by the business process deployment transaction process contract; if not, refuse to deploy the business process contract specified by said business process deployment transaction.
  • the network governance contract can be deployed in the blockchain subnet.
  • the business process contract deployment transaction that calls the smart contract of this network can be submitted to the blockchain subnet.
  • the governance contract of this network is based on the voting mechanism mentioned above, triggering a vote Deploy the business process contract in the blockchain subnet Deploy the business process contract specified by the transaction.
  • Each voting party can refer to the contract pre-registration information in the genesis block of the blockchain subnet to vote.
  • the genesis block of the blockchain network may contain contract pre-registration information, and the contract pre-registration information includes: one or more business process contracts that are allowed to be deployed on the blockchain network contract hash.
  • the manner of deploying the business process contract for the blockchain network may specifically be that the nodes of the blockchain network acquire the business process contract deployment transaction; verify the contract hash of the business process contract specified by the business process contract deployment transaction, Whether it is recorded in the contract pre-registration information in the genesis block; if yes, deploy the business process contract specified by the business process deployment transaction; if not, refuse to deploy the business process contract specified by the business process deployment transaction.
  • the subnet of the main network can also deploy its own network governance contract and subnet management contract.
  • a subnet can also create its own subnet.
  • each subnet node of the blockchain subnet obtains a subnet creation transaction that invokes the governance contract of this network; the subnet creation transaction specifies the subnet configuration information , the subnetwork configuration information includes: the identity information of members participating in the subnetwork; each subnetwork node executes the local network governance contract: triggers a voting event for creating a transaction in the subnetwork; each voting party client is monitoring After the voting event, judge whether to allow the subnet to create a transaction, and based on the judgment result, submit a voting transaction that calls the governance contract of the network to the blockchain subnet; the nodes of each subnet continue to execute the governance contract of the network: according to For each voting transaction received, if the vote is confirmed to be passed, call the subnet management contract;
  • the genesis block of the created subnet can also contain contract pre-registration information, allowing subsequent business process contracts to be deployed in the created subnet It also needs to match the contract pre-registration information.
  • the embodiment of how to deploy the business process contract in the created sub-network can be understood by referring to the above, and will not be repeated here.
  • the flowchart of another method for creating a blockchain subnet includes the following steps: 1. Each main network node acquires a subnet creation transaction that invokes the governance contract of the local network.
  • Each main network node deploys the network governance contract, subnet management contract and business process management contract.
  • the business process management contract is used to record the corresponding relationship between the created subnet and the contract pre-registration information, and can provide the corresponding relationship query function.
  • the subnet creation transaction specifies the subnet configuration information, which includes: the identity information of members participating in the subnet and contract pre-registration information; the contract pre-registration information includes: allowing deployment in the created subnet The contract hash of one or more orchestration contracts in .
  • the main difference between this method and the previous subnet creation method is that the business process management contract is also deployed on the main network node.
  • the local network governance contract no longer calls the subnet management contract, but It is to call the process management contract when the vote is passed, and pass the subnet configuration information to the process management contract, and then the process management contract calls the subnet management contract (the subnet configuration information is further passed to the subnet management contract)
  • the network is created, and the process management contract records the correspondence between the created subnet and the contract pre-registration information.
  • Each main network node executes the governance contract of this network: triggers a voting event for creating a transaction on this subnet.
  • each voting client monitors the voting event, it judges whether to allow the subnet to create a transaction, and based on the judgment result, submits a voting transaction that calls the governance contract of this network to the main network.
  • Each main network node continues to execute the governance contract of the network: according to the received voting transactions, when the vote is confirmed to pass, call the business process management contract.
  • Each main network node executes the business process management contract: calls the subnet management contract, and saves the corresponding relationship between the network identifier of the subnet to be created and the pre-registration information of the contract.
  • the process management contract assigns a network identifier to the subnet to be created, and establishes a correspondence between the network identifier and contract pre-registration information.
  • the subnetwork management contract assigns the subnet ID to the subnet to be created. In this case, the subnet management contract needs to return the subnet ID to the process management contract after being called by the process management contract .
  • the main network node on the node device of each member participating in the subnet deploys the subnet node after listening to the subnet creation event.
  • each main network node obtains the query transaction for invoking the process management contract; the query transaction specifies the network identifier of the subnet created by the main network; each main network node executes the process management contract: query the contract reservation corresponding to the network identifier Registration information, returns the queried contract pre-registration information to the client that submitted the query transaction.
  • the subnet created by the main network can also further create the next-level subnet.
  • each subnet node of any blockchain subnet obtains the subnet creation transaction that calls the governance contract of this network; the subnet creation transaction specifies Subnet configuration information, the subnet configuration information includes: the identity information of members participating in the subnet and contract pre-registration information; the contract pre-registration information includes: one or more services that are allowed to be deployed in the created subnet
  • the contract hash of the process contract each subnetwork node executes the local network governance contract: triggers a voting event for creating a transaction for the subnetwork; each voting party client determines whether to allow the subnetwork after listening to the voting event Create a transaction, and submit a voting transaction calling the governance contract of this network to the blockchain subnet based on the judgment result; each subnet node continues to execute the governance contract of this network: In this case, call the business process management contract; each subnetwork node executes the business process management contract: call the subnetwork management contract, and save the corresponding relationship between the
  • Each main network node obtains the subnet creation transaction that invokes the smart contract.
  • the subnet creation transaction specifies subnet configuration information, and the subnet configuration information includes: identity information of members participating in the subnet;
  • Each main network node executes the smart contract: triggers a voting event for creating a transaction on the subnet.
  • each voting client monitors the voting event, it judges whether to allow the subnet to create a transaction, and based on the judgment result, submits a voting transaction that calls the governance contract of this network to the main network.
  • Each main network node continues to execute the smart contract: according to the received voting transactions, if the vote is confirmed to be passed, the subnet creation event is triggered according to the subnet configuration information.
  • the main network node on the node device of each member participating in the subnet deploys the subnet node after listening to the subnet creation event.
  • the subnet configuration information may also include contract pre-registration information; the contract pre-registration information includes contract hashes of one or more business process contracts that are allowed to be deployed in the created subnet.
  • each main network node can also save the corresponding relationship between the network identifier of the subnet to be created and the pre-registration information of the contract.
  • Each main network node obtains the query transaction that calls the smart contract; the query transaction specifies the network identifier of the subnet created by the main network; each main network node executes the smart contract: query the contract pre-registration information corresponding to the network identifier, and query The received contract pre-registration information is returned to the client that submitted the query transaction.
  • this paper provides a device for scheduling computing services for business process contracts.
  • the business process contracts are deployed on the blockchain network.
  • Each computing task used to implement the business process is defined in the business process contract, and the participating At least one node for each computing task; the method is applied to a scheduling process that is also running on the node device corresponding to each node, and the device includes: a scheduling module, for at least part of the computing tasks defined in the business process contract,
  • a computing service process that is still running on the corresponding node device corresponding to the computing type and in an available state is scheduled to be occupied by the computing task.
  • computing service process wherein, in the process of executing the business process contract, the blockchain network calls the computing service process occupied by each computing task through the scheduling process to execute the computing task.
  • This article provides a block chain network, on which a business process contract is deployed, and each computing task used to realize the business process is defined in the business process contract, and each computing task that participates in each computing task is specified At least one node; a node-independent scheduling process running on the node device corresponding to each node, for at least part of the computing tasks defined in the business process contract, if it is determined that the corresponding node participates in the computing task, according to the For the calculation type of the calculation task, a calculation service process corresponding to the calculation type and in the available state that is still running on the corresponding node device is scheduled as the calculation service process occupied by the calculation task; wherein, the blockchain network is in During the execution of the business process contract, the scheduling process invokes the computing service process occupied by each computing task to execute the computing task.
  • This paper also provides a blockchain network on which a business process contract is deployed, and each computing task used to realize the business process is defined in the business process contract, and each computing task that participates in each computing task is specified.
  • at least one node for at least part of the computing tasks defined in the business process contract, the node devices that run the nodes participating in the computing tasks also run: the computing service process occupied by the computing task and the scheduling for scheduling the computing service process process;
  • each node in the blockchain network obtains the business transaction calling the business process contract, and executes the business process contract according to the business transaction: for the at least part of the computing tasks, if it participates in the business process contract If the computing task meets the start conditions of the computing task, a request event for the computing task is triggered; the scheduling process corresponding to each node, after listening to the request event, invokes the computing service process occupied by the computing task; obtains the Calculate the calculation result returned by the service process, and submit the calculation result transaction calling the business process contract to the blockchain network based on the calculation result.
  • a typical implementing device is a computer.
  • 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.
  • 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.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • 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.
  • 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.
  • 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.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • 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.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Mathematical Physics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本说明书一个或多个实施例提供一种为业务流程合约调度计算服务的方法。在至少部分节点对应的节点设备上运行独立于节点的调度进程,调度进程用于调度该节点设备上运行的独立于节点的计算服务进程。对于业务流程合约中的每个计算任务,参与该计算任务的节点对应的调度进程,根据该计算任务的计算类型,将同一节点设备上的一个可占用的、对应于该计算类型的计算服务进程调度为服务于该计算任务的计算服务进程。如此,区块链网络在执行业务流程合约的过程中,可以通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。

Description

为业务流程合约调度计算服务的方法 技术领域
本说明书一个或多个实施例涉及终端技术领域,尤其涉及一种为业务流程合约调度计算服务的方法。
背景技术
区块链技术构建在传输网络(例如点对点网络)之上。传输网络中的网络节点利用链式数据结构来验证与存储数据,并采用分布式节点共识算法来生成和更新数据。
在实际应用中,有时需要在区块链网络中部署业务流程合约(用于实现特定业务流程的智能合约),然而,业务流程合约涉及的全部计算是由区块链网络的节点执行的,业务流程的推进效率对节点的运行状态有较强的依赖性。
发明内容
有鉴于此,本说明书实施例提供一种为业务流程合约调度计算服务的方法。
为实现上述目的,根据本说明书一个或多个实施例的第一方面,提出了一种为业务流程合约调度计算服务的方法,区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;所述方法应用于每个节点对应的节点设备上还运行的调度进程,所述方法包括:针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
根据本说明书一个或多个实施例的第二方面,提出了一种为业务流程合约调度计算服务的装置,区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;所述方法应用于每个节点对应的节点设备上还运行的调度进程,所述装置包括:调度模块,针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
根据本说明书一个或多个实施例的第三方面,提出了一种区块链网络,所述区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;每个节点对应的节点设备上还运行的独立于节点的调度进程,针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
本说明书一个或多个实施例提供的技术方案,在至少部分节点对应的节点设备上运行独立于节点的调度进程,调度进程用于调度该节点设备上运行的独立于节点的计算服务进程。对于业务流程合约中的每个计算任务,参与该计算任务的节点对应的调度进程,根据该计算任务的计算类型,将同一节点设备上的一个可占用的、对应于该计算类型的计算服务进程调度为服务于该计算任务的计算服务进程。如此,区块链网络在执行所述业务流程合约的过程中,可以通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
基于上述技术方案,节点执行业务流程合约的过程中,并不需要直接执行每个计算 任务,而是将至少部分计算任务交给独立于节点的计算服务进程来直接执行,从而减弱了业务流程的推进效率对节点运行状态的依赖性,即便节点运行异常,也不容易拖延业务流程的推进。此外,即便某个计算任务执行异常,也可能不需要节点进行异常修复,也不容易影响节点的运行状态。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图。
图2是一示例性实施例提供的一种调用智能合约的示意图。
图3是一示例性实施例提供的一种创建和调用智能合约的示意图。
图4是一示例性实施例提供的一种区块链子网的组建方法的流程图。
图5是一示例性实施例提供的一种基于区块链主网组建区块链子网的示意图。
图6是一示例性实施例提供的另一种组建区块链子网的方法的流程图。
图7是一种为业务流程合约调度计算服务的方法的流程示意图。
图8是一种基于链外的计算服务的业务执行方法的流程示意图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。在其他实施例中不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。
区块链一般被划分为三种类型:公有链(Public Blockchain),私有链(Private Blockchain)和联盟链(Consortium Blockchain)。还有多种类型的结合,比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且,各参与者(即节点)可自由加入以及退出网络,并进行相关操作。私有链则相反,该网络的写入权限由某个组织或者机构控制,数据读取权限受组织规定。简单来说,私有链可以为一个弱中心化系统,参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织;参与者通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
不论是公有链、私有链还是联盟链,都可能提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑,这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,虚拟机直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。
例如图1所示,Bob将一个包含创建智能合约信息的交易发送到以太坊网络后,节点1的EVM可以执行这个交易并生成对应的合约实例。图1中的“0x6f8ae93…”代表了这个合约的地址,交易的data字段保存的可以是字节码,交易的to字段为空。节点间通过共识机制达成一致后,这个合约成功创建,并且可以在后续过程中被调用。合约创建后,区块链上出现一个与该智能合约对应的合约账户,并拥有一个特定的地址,合约代码将保存在该合约账户中。智能合约的行为由合约代码控制。换句话说,智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
如图2所示,仍以以太坊为例,Bob将一个用于调用智能合约的交易发送到以太坊网络后,某一节点的EVM可以执行这个交易并生成对应的合约实例。图2中交易的from 字段是交易发起方(即Bob)的账户的地址,to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址,value字段在以太坊中是以太币的值,交易的data字段保存的调用智能合约的方法和参数。调用智能合约后,balance的值可能改变。后续,某个客户端可以通过某一区块链节点(例如图2中的节点6)查看balance的当前值。智能合约以规定的方式在区块链网络中每个节点独立的执行,所有执行记录和数据都保存在区块链上,所以当交易完成后,区块链上就保存了无法篡改、不会丢失的交易凭证。
创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约,需要经过编写智能合约、编译成字节码、部署到区块链等过程。以太坊中调用智能合约,是发起一笔指向智能合约地址的交易,智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
除了可以由用户创建智能合约,也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的,创世合约中可以设置一些区块链网络的数据结构、参数、属性和方法。具有系统管理员权限的账户可以创建系统级的合约,或者修改系统级的合约(简称为系统合约)。另外除了以太坊中的EVM外,不同的区块链网络还可能采用各种的虚拟机,这里并不限定。
区块链网络中的节点在执行调用智能合约的交易后,会生成相应的收据(receipt),以用于记录与执行该智能合约相关的信息。这样,可以通过查询交易的收据来获得合约执行结果的相关信息。合约执行结果可以表现为收据中的事件(event)。消息机制可以通过收据中的事件实现消息传递,以触发区块链节点或部署该区块链节点的节点设备执行相应的处理。事件的结构譬如可以为:
Event:
[topic][data]
[topic][data]
......
在上述示例中,事件的数量可以为一个或多个;其中,每个事件分别包括主题(topic)和数据(data)等字段。区块链节点或部署该区块链节点的节点设备可以通过监听事件的topic,从而在监听到预定义的topic的情况下,执行预设处理,或者从相应事件的data字段读取相关内容,以及可以基于读取的内容执行预设处理。
上述的事件机制中,相当于在监听方(比如存在监听需求的用户)处存在具有监听功能的客户端,譬如该客户端上运行了用于实现监听功能的SDK等,由该客户端对区块链节点产生的事件进行监听,而区块链节点只需要正常生成收据即可。除了上述的事件机制之外,还可以通过其他方式实现交易信息的透出。例如,可以通过在区块链节点运行的区块链平台代码中嵌入监听代码,使得该监听代码可以监听区块链交易的交易内容、智能合约的合约状态、合约产生的收据等其中的一种或多种数据,并将监听到的数据发送至预定义的监听方。由于监听代码部署于区块链平台代码中,而非监听方的客户端处,因而相比于事件机制而言,这种基于监听代码的实现方式相对更加的主动。其中,上述的监听代码可以由区块链平台的开发人员在开发过程中加入区块链平台代码,也可以由监听方基于自身的需求而嵌入,本说明书并不对此进行限制。
区块链技术区别于传统技术的去中心化特点之一,就是在各个节点上进行记账,或者称为分布式记账,而不是传统的集中式记账。区块链系统要成为一个难以攻破的、公开的、不可篡改数据记录的去中心化诚实可信系统,需要在尽可能短的时间内做到分布式数据记录的安全、明确及不可逆。不同类型的区块链网络中,为了在各个记录账本的节点中保持账本的一致,通常采用共识算法来保证,即前述提到的共识机制。例如,区块链节点之间可以实现区块粒度的共识机制,比如在节点(例如某个独特的节点)产生一个区块后,如果产生的这个区块得到其它节点的认可,其它节点记录相同的区块。再例如,区块链节点之间可以实现交易粒度的共识机制,比如在节点(例如某个独特的节点)获取一笔区块链交易后,如果这笔区块链交易得到其他节点的认可,认可该区块链 交易的各个节点可以分别将该区块链交易添加至自身维护的最新区块中,并且最终能够确保各个节点产生相同的最新区块。共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制,可以保证最新区块被准确添加至区块链。当前主流的共识机制包括:工作量证明(Proof of Work,POW)、股权证明(Proof of Stake,POS)、委任权益证明(Delegated Proof of Stake,DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance,PBFT)算法,HoneyBadgerBFT算法等。
硬件层面的区块链网络通常是由多个成员的节点设备组成。每个成员的节点设备上部署了节点,各成员的节点设备上部署的节点又组成了软件层面的区块链网络。
不同的成员是不同的个人或机构,实际上相当于不同的利益方。一个成员的节点设备可以有多个(即设备集群),该成员可以灵活(例如考虑单个设备的性能)在设备集群中部署若干属于不同区块链网络的节点,通过不同节点参与不同区块链网络中的交易。
节点是软件层面的概念,一个节点可以理解为用于实现节点功能的代码的一个实例(一个进程或一个线程),如此,相当于同一成员的节点设备上可以部署多个用于实现节点功能的实例。对于联盟链网络的情况,节点的控制方是联盟成员(机构),而客户端的控制方是机构对接的用户,因此,这多个节点可以通过节点设备的不同端口(或者同一默认端口)与客户端进行通信,接收客户端提交的交易。
而对于公有链网络的情况,节点包含于客户端,节点的控制方就是客户端的控制方,即用户,因此,这多个节点可以包含于同一客户端,用户可以选择一个节点提交交易。
在本文中,为了方便描述,“节点接收客户端提交的交易”既可以指联盟链网络的情况,又可以指公有链网络的情况。
由于区块链网络的去中心化特性,使得区块链网络中的所有区块链节点均会维护相同的区块数据,无法满足部分节点的特殊需求。以现有的联盟链网络为例,所有联盟成员(即联盟内的节点成员)的节点设备上都部署有该联盟链网络的节点,可以组成一区块链网络,即所有联盟成员在该区块链网络中分别存在对应的区块链节点,并可以通过对应的区块链节点获得该区块链网络上发生的所有交易和相关数据。但在一些情况下,可能存在部分联盟成员希望小范围内完成一些具有保密需求的交易,这些联盟成员既希望这些交易能够在区块链上存证或借助于区块链技术的其他优势,又能够避免其他联盟成员查看到这些交易和相关数据。
为此,本说明书实施例提供一种由多个成员参与的区块链系统,该系统在硬件层面包括每个成员的节点设备,每个成员的节点设备上部署至少一个节点,同一成员的节点设备上部署的不同节点属于不同区块链网络。同时,该系统在软件层面具有以区块链主网为根结点、各个区块链子网分别为其他结点的树形结构。
本文所述的节点与结点是不同概念。节点是区块链意义上的概念,是指区块链网络中的节点;而结点是树形结构中的概念,在本文中代指树形结构中的一个区块链网络。
区块链主网可以认为是系统中最上一级的区块链网络,其通常由系统的全部成员的节点设备上部署的主网节点组成。在有些实施例中,成员可以有初始成员(参与初始化系统的成员)与后续成员(系统初始化之后加入的成员)之分。全部初始成员构建区块链系统,系统中的区块链主网由全部初始成员的节点设备上部署的主网节点组成,而后续,更多的后续成员可以加入区块链系统,后续成员的节点设备上可以部署主网节点,从而加入主网,也可以不部署主网节点,仅仅部署一个或多个子网节点。
系统中的区块链子网可以有多级。最上一级的区块链子网是区块链主网在树形结构中的子结点。区块链子网也可以有下一级区块链子网的子结点。通常而言,一个区块链子网的节点对应的节点设备上,同时也部署了区块链主网的主网节点。而在系统中存在初始成员与后续成员之分的实施例中,一个区块链子网的节点对应的节点设备可能是后续成员的节点设备,这个后续成员的节点设备有可能没有部署主网节点。
通过这样的区块链系统,个别成员可以自行组建区块链子网进行小范围交易,系统 中的各区块链网络(不论是主网还是子网)是相互数据隔离的。
在有些实施例中,区块链网络的创建方式可以是,由每个成员在自己的节点设备上进行手动部署,如果一个成员的节点设备上需要部署3个不同区块链网络(一个主网,两个子网)的节点,那么需要这个成员对节点设备进行三次手动部署区块链网络的流程。然而,对于成员来说,每次需要在自己的节点设备上增加部署一个新区块链网络的节点,就需要成员重新执行手动部署流程,这比较麻烦。况且,一些成员之间小范围的交易需求往往是临时的或者具有一定的时效性,使得手动部署的新的区块链子网很快就会由于需求消失而失去存在的意义,而取消该区块链子网又需要成员对节点设备进行手动操作,更增加了麻烦。
为此,在有些实施例中,提出另外一种在系统中创建区块链网络的方法。将系统中最初组建的区块链主网作为基础,在该区块链主网的基础上组建区块链子网。
具体来说,区块链主网受理子网创建交易并基于部署的合约处理子网创建交易,触发子网创建事件,每个主网节点监听到子网创建事件后,如果确定自身对应的节点设备的成员参与该子网,则根据子网创建交易携带的配置信息,创建一个实例,作为创建的子网的节点。而每个区块链子网也可以进一步受理子网创建交易并基于部署的合约处理子网创建交易,触发子网创建事件,该区块链子网中的每个子网节点从该子网节点监听到子网创建事件之后,如果确定自身对应的节点设备的成员参与该下一级子网,则根据子网创建交易携带的配置信息,创建一个实例,作为进一步创建的下一级子网的节点。
在本文中,对于任一区块链子网,如果负责处理用于创建该区块链子网的子网创建交易的区块链网络,即被称为创建该区块链子网的区块链网络,是树形结构中该区块链子网的父结点。在树形结构中,父结点的子结点的区块链子网不一定是父结点创建的,但是依然可以由父结点管理(即父结点的区块链网络中记录了子结点的区块链子网的网络标识与地址信息)。
在这些实施例中,任一区块链子网由其父结点对应的区块链网络所创建与管理。这样的方式,成员通常仅需要在自己的节点设备上完成一次主网节点的手动部署即可,后续部分成员的节点设备上的主网节点可以创建新的实例作为下一级的子网节点。部分成员的节点设备上的某个区块链子网的节点又可以进一步创建新的实例作为更下一级的子网节点。通过这样的层级式地网络部署方式,可以减少成员手动部署的麻烦。
在这些实施例中,一些后续成员的节点设备依然可在部署了区块链子网之后再加入到系统中,这意味着该区块链子网不是系统中原先的任何区块链网络创建的,而是直接从外部加入到系统中的区块链子网,这种区块链子网依然可加入树形结构中,成为一个结点,只不过该结点的区块链子网是由其父结点对应的区块链网络所管理(而非创建)。
通过上述的子网创建与管理方式,任一区块链子网要么是父结点的区块链网络所创建与管理的,要么是从外部直接加入到树形结构中,由父结点的区块链网络所管理的。不论是哪种情况,任一区块链子网的地址信息(即包含的每个节点的地址信息,如IP地址、端口号)可以只暴露给其父结点的区块链网络,由其父结点的区块链网络中的每个节点进行记录。如此一来,可以最大限度保证子网隐私,降低网络攻击的风险。
以下结合图4对本说明书的区块链子网的组建方案进行说明。下文中的节点成员具体是指成员;节点设备是指成员控制的设备,是硬件层面的概念;节点是指节点实例(节点设备上运行的进程或线程),部署在节点设备上,是软件层面的概念。
请参见图4,图4是一示例性实施例提供的一种组建区块链子网的方法的流程图。如图4所示,该方法可以包括以下步骤:步骤402,区块链主网中的各区块链节点分别获取组建区块链子网的交易,所述交易包含所述区块链子网的配置信息,所述配置信息包括参与组建所述区块链子网的节点成员的身份信息。
组建区块链子网的交易可由区块链主网的管理员发起,即仅允许管理员在区块链主网的基础上组建区块链子网,而避免将区块链子网的组建权限开放给普通用户,以防止 由此导致的安全性问题。在一些情况下,也可以允许区块链主网的普通用户发起上述组建区块链子网的交易,以满足普通用户的组网需求,使得普通用户能够在管理员不便于发起交易的情况下依然能够快捷地组建区块链子网。
以图5所示为例,区块链主网为subnet0,该subnet0包含的区块链节点为nodeA、nodeB、nodeC、nodeD和nodeE等。假定nodeA、nodeB、nodeC和nodeD分别对应的节点成员希望组建一区块链子网:如果nodeA为管理员且仅允许管理员发起组建区块链子网的交易,那么可由nodeA向subnet0发起上述组建区块链子网的交易;如果nodeE为管理员且仅允许管理员发起组建区块链子网的交易,那么nodeA~nodeD需要向nodeE进行请求,使得nodeE向subnet0发起上述组建区块链子网的交易;如果nodeE为管理员但允许普通用户发起组建区块链子网的交易,那么nodeA~nodeE均可以向subnet0发起上述组建区块链子网的交易。当然,不论是管理员或者普通用户,发起组建区块链子网的交易的区块链节点对应的节点成员并不一定参与所组建的区块链子网,比如虽然最终由nodeA、nodeB、nodeC和nodeD分别对应的节点成员组建区块链子网,但可由nodeE向subnet0发起上述组建区块链子网的交易,而并不一定由nodeA~nodeD来发起该组建区块链子网的交易。
在区块链主网的基础上组建区块链子网时,容易理解的是,会使得该区块链子网与区块链主网之间存在逻辑上的层次关系。比如在图5所示的subnet0上组建区块链子网subnet1时,可以认为subnet0处于第一层、subnet1处于第二层。一种情况下,本说明书中的区块链主网可以为底层区块链网络,即区块链主网并非在其他区块链网络的基础上组建的区块链子网,比如图5中的subnet0可以认为属于底层区块链网络类型的区块链主网。另一种情况下,本说明书中的区块链主网可以为其他区块链网络的子网,比如可以在图5中subnet1的基础上进一步组建另一区块链子网,此时可以认为subnet1为该区块链子网对应的区块链主网,而这并不影响该subnet1同时属于subnet0上创建的区块链子网。可见,区块链主网与区块链子网实际上是相对概念,同一区块链网络在一些情况下可以为区块链主网、另一些情况下可以为区块链子网。
步骤404,所述区块链主网中的各区块链节点执行所述交易以透出所述配置信息。
步骤406,当所述配置信息包含第一区块链节点对应的节点成员的身份信息时,部署第一区块链节点的节点设备基于所述包含所述配置信息的创世块启动属于所述区块链子网的第二区块链节点。
上述组建区块链子网的交易在被发送至区块链主网后,由区块链主网内的共识节点进行共识,并在通过共识后由各区块链节点执行该交易,以完成区块链子网的组建。共识过程取决于所采用的共识机制,譬如上文所述任一共识机制,本文不对此进行限制。
通过在上述组建区块链子网的交易中包含配置信息,该配置信息可以用于对所组建的区块链子网进行配置,使得组建的区块链子网符合组网需求。例如,通过在配置信息中包含参与组建所述区块链子网的节点成员的身份信息,可以指定组建的区块链子网对应于哪些节点成员。
节点成员的身份信息可以包括公钥,或者采用节点ID等其他能够表征节点成员的身份的信息,本说明书并不对此进行限制。以公钥为例,每个区块链节点都存在对应的一组或多组公私钥对,由区块链节点持有私钥而公钥被公开且唯一对应于该私钥,因而可以通过公钥来表征相应区块链节点的身份,也可以通过该公钥来表征该区块链节点对应的节点成员的身份。因此,对于希望参与组建区块链子网的节点成员,可以将这些节点成员在区块链主网上对应的区块链节点的公钥添加至上述组建区块链子网的交易中,以作为上述节点成员的身份信息。上述的公私钥对可以用于签名验证的过程。例如,在采用有签名的共识算法中,譬如subnet1上述的nodeA1采用自身维护的私钥对消息进行签名后,将经过签名的消息在subnet1中广播,而nodeB1、nodeC1和nodeD1可以用nodeA1的公钥对收到的消息进行签名验证,以确认自身收到的消息确实来自nodeA1且 没有经过篡改。
第一区块链节点可以为区块链主网上属于配置信息所指示的节点成员对应的区块链节点。在组建区块链子网时,并非由第一区块链节点直接参与组建区块链子网,而是需要由用于部署该第一区块链节点的节点设备生成第二区块链节点,并由第二区块链节点参与组建区块链子网。第一区块链节点和第二区块链节点对应于同一个节点成员,比如在联盟链场景下对应于同一联盟链成员,但第一区块链节点属于区块链主网、第二区块链节点属于区块链子网,使得该节点成员可以分别参与到区块链主网和区块链子网的交易中;并且,由于区块链主网和区块链子网属于相互独立的两个区块链网络,使得第一区块链节点生成的区块与第二区块链节点生成的区块分别存入所述节点设备上的不同存储(采用的存储譬如可以为数据库),实现了第一区块链节点与第二区块链节点分别使用的存储之间的相互隔离,因而区块链子网所产生的数据仅会在区块链子网中的各个区块链节点之间同步,使得仅参与了区块链主网的节点成员无法获得区块链子网上产生的数据,实现了区块链主网与区块链子网之间的数据隔离,满足了部分节点成员(即参与区块链子网的节点成员)之间的交易需求。
第一区块链节点和第二区块链节点是在逻辑上划分出来的区块链节点,而从物理设备的角度来说,相当于上述部署了第一区块链节点和第二区块链节点的节点设备同时参与了区块链主网和区块链子网。由于区块链主网与区块链子网之间相互独立,使得这两个区块链网络的身份体系也相互独立,因而即便第一区块链节点和第二区块链节点可以采用完全相同的公钥,仍然应当将两者视为不同的区块链节点。譬如在图5中,subnet0中的nodeA相当于第一区块链节点,而部署该nodeA的节点设备生成了属于subnet1的nodeA1,该nodeA1相当于第二区块链节点。可见,由于身份体系相互独立,所以即便第二区块链节点所采用的公钥区别于第一区块链节点,也不影响本说明书方案的实施。
当然,参与区块链子网的节点成员并不一定只是参与区块链主网的节点成员中的一部分。在一些情况下,参与区块链子网的节点成员可以与参与区块链主网的节点成员完全一致,此时所有的节点成员都可以获得区块链主网和区块链子网上的数据,但是区块链主网与区块链子网所产生的数据依然可以相互隔离,比如可以通过在区块链主网上实现一类业务、在区块链子网上实现另一类业务,从而可以使得这两类业务分别产生的业务数据之间相互隔离。
除了上述的节点成员的身份信息之外,配置信息还可以包括下述至少之一:所述区块链子网的网络标识、所述区块链子网的管理员的身份信息、针对区块链平台代码的属性配置等,本说明书并不对此进行限制。网络标识用于唯一表征该区块链子网,因而该区块链子网的网络标识应当区别于区块链主网和该区块链主网上组建的其他区块链子网。区块链子网的管理员的身份信息,譬如可以为作为管理员的节点成员的公钥;其中,区块链主网与区块链子网的管理员可以相同,也可以不同。
通过区块链主网来组建区块链子网的优势之一,就是由于生成第二区块链节点的节点设备上已经部署了第一区块链节点,因而可以将第一区块链节点所使用的区块链平台代码复用在第二区块链节点上,免去了区块链平台代码的重复部署,极大地提高了区块链子网的组建效率。如果配置信息中未包含针对区块链平台代码的属性配置,第二区块链节点可以复用第一区块链节点上采用的属性配置;如果配置信息中包含了针对区块链平台代码的属性配置,第二区块链节点可以采用该属性配置,使得第二区块链节点所采用的属性配置不受限于第一区块链节点的属性配置、与第一区块链节点无关。针对区块链平台代码的属性配置可以包括下述至少之一:代码版本号、是否需要共识、共识算法类型、区块大小等,本说明书并不对此进行限制。
组建区块链子网的交易包括调用合约的交易。该交易中可以指明被调用的智能合约的地址、调用的方法和传入的参数。例如,调用的合约可以为前述的创世合约或系统合约,调用的方法可以为组建区块链子网的方法,传入的参数可以包括上述的配置信息。 在一实施例中,该交易可以包含如下信息:
from:Administrator
to:Subnet
method:AddSubnet(string)
string:genesis
其中,from字段为该交易的发起方的信息,譬如Administrator表明该发起方为管理员;to字段为被调用的智能合约的地址,譬如该智能合约可以为Subnet合约,则to字段具体为该Subnet合约的地址;method字段为调用的方法,譬如在Subnet合约中用于组建区块链子网的方法可以为AddSubnet(string),而string为AddSubnet()方法中的参数,上述示例中通过genesis表征该参数的取值,该genesis具体为前述的配置信息。
以Subnet0上的节点nodeA~nodeE执行调用Subnet合约中AddSubnet()方法的交易为例。在交易通过共识后,nodeA~nodeE分别执行AddSubnet()方法并传入配置信息,得到相应的执行结果。
合约的执行结果可包括所述配置信息,该执行结果可处于前文所述的收据中,该收据中可包含与执行AddSubnet()方法相关的event,即组网事件。组网事件的topic可包含预定义的组网事件标识,以区别于其他的事件。譬如在与执行AddSubnet()方法相关的event中,topic的内容为关键词subnet,且该关键词区别于其他方法所产生event中的topic。nodeA~nodeE或者部署nodeA~nodeE的节点设备1~5通过监听生成的收据中各个event所含的topic,可在监听到包含关键词subnet的topic的情况下,确定监听到与执行AddSubnet()方法相关的event,即组网事件。例如,收据中的event如下:
Event:
[topic:other][data]
[topic:subnet][data]
......
在监听到第1条event时,由于所含topic的内容为other,确定该event与AddSubnet()方法无关;在监听到第2条event时,由于所含topic的内容为subnet,确定该event与AddSubnet()方法相关,并读取该event对应的data字段,该data字段包含上述的配置信息。以配置信息包括区块链子网的节点成员的公钥为例,data字段的内容例如可包括:
{subnet1;
nodeA的公钥,nodeA的IP、nodeA的端口号…;
nodeB的公钥,nodeB的IP、nodeB的端口号…;
nodeC的公钥,nodeC的IP、nodeC的端口号…;
nodeD的公钥,nodeD的IP、nodeD的端口号…;
}
其中,subnet1为希望创建的区块链子网的网络标识。区块链主网中的各个区块链节点可以记录该区块链主网上已创建的所有区块链子网的网络标识,或者与这些区块链子网相关的其他信息,这些信息譬如可以维护在上述的Subnet合约中,具体可以对应于该Subnet合约所含的一个或多个合约状态的取值。可以根据记录的已创建的所有区块链子网的网络标识,确定上述的subnet1是否已经存在;如果不存在,说明subnet1是当前需要创建的新区块链子网,如果存在则说明subnet1已经存在。
除了采用希望创建的新的区块链子网的网络标识之外,还可以采用预定义的新建网络标识,该新建网络标识表明相应的组网事件用于组建新的区块链子网。例如,可以将上述的subnet1替换为newsubnet,该newsubnet为预定义的新建网络标识,nodeA~nodeE在识别到data字段包含newsubnet时,即可确定包含该newsubnet的event为组网事件,需要创建新的区块链子网。
除了网络标识subnet1之外,上述data字段中还包含参与组建区块链子网的各个节点成员的身份信息等内容。部署第一区块链节点的节点设备可以监听生成的收据,并在 监听到所述组网事件且所述组网事件的内容包含第一区块链节点对应的节点成员的身份信息的情况下,由部署第一区块链节点的节点设备获取所述组网事件包含的配置信息或创世块。或者,第一区块链节点可以监听生成的收据,并在监听到所述组网事件且所述组网事件的内容表明第一区块链节点属于所述节点成员的情况下,触发部署第一区块链节点的节点设备获取所述组网事件包含的所述配置信息或所述创世块。
如前所述,节点设备可以直接监听收据。假定nodeA~nodeE分别部署在节点设备1~5上,节点设备1~5可以监听nodeA~nodeE分别生成的收据,那么在监听到subnet1是需要新组建的区块链子网的情况下,节点设备1~5会进一步识别data字段中包含的节点成员的身份信息,以确定自身的处理方式。以nodeA和节点设备1为例:如果节点设备1发现data字段包含nodeA的公钥、IP地址和端口号等身份信息,那么节点设备1在基于上述的消息机制从data字段获得配置信息的情况下,生成包含该配置信息的创世块,且节点设备1会在本地部署nodeA1,该nodeA1加载生成的创世块,从而成为subnet1的子网节点;类似地,节点设备2可以生成nodeB1、节点设备3可以生成nodeC1、节点设备4可以生成nodeD1。以及,节点设备5会发现data字段包含的身份信息与自身均不匹配,则该节点设备5不会根据data字段中的配置信息生成创世块,也不会生成subnet1中的区块链节点。
如前所述,区块链主网中的区块链节点可以监听收据,并根据监听结果触发节点设备执行相关处理。例如,nodeA~nodeE在确定subnet1是需要新组建的区块链子网的情况下,会进一步识别data字段中包含的节点成员的身份信息,以确定自身的处理方式。比如,nodeA~nodeD会发现在data字段包含自身的公钥、IP地址和端口号等身份信息,假定nodeA~nodeD分别部署在节点设备1~4上,以nodeA和节点设备1为例:nodeA会触发节点设备1,使得节点设备1在基于上述的消息机制从data字段获得配置信息的情况下,生成包含该配置信息的创世块,且节点设备1会在本地部署nodeA1,该nodeA1加载生成的创世块,从而成为subnet1的子网节点;类似地,nodeB会触发节点设备2生成nodeB1、nodeC会触发节点设备3生成nodeC1、nodeD会触发节点设备4生成nodeD1。以及,nodeE会发现data字段包含的身份信息与自身均不匹配,假定nodeE部署在节点设备5上,那么该节点设备5不会根据data字段中的配置信息生成创世块,也不会生成subnet1中的区块链节点。
如前所述,第一区块链节点与第二区块链节点并不一定采用相同的身份信息。因此,在上述实施例中,data字段中可以包含预先为nodeA1~nodeD1生成的身份信息,且区别于nodeA~nodeD的身份信息。仍以nodeA和节点设备1为例:节点设备1如果在data字段中发现了nodeA1的身份信息,可以生成创世块、部署nodeA1,并由nodeA1加载该创世块;或者,nodeA如果在data字段中发现了nodeA1的身份信息,那么nodeA会触发节点设备1生成创世块、部署nodeA1,并由nodeA1加载该创世块。其他区块链节点或节点设备的处理方式类似,此处不再一一赘述。
除了配置信息之外,合约的执行结果可以包括创世块。换言之,除了可以在data字段中包含配置信息,还可以直接在执行合约调用的过程中生成包含配置信息的创世块,从而将创世块包含于data字段中,那么对于上述的nodeA~nodeD而言,相应的节点设备1~4可以通过消息机制直接从data字段获得创世块,而无需自行生成,可以提升对nodeA1~nodeD1的部署效率。
在本说明书中,组建区块链子网的交易可以并非是调用智能合约的交易,使得不支持智能合约的区块链网络也可以实现本说明书的技术方案,从而在区块链主网的基础上快捷地创建出区块链子网。例如,可以预先定义一组网交易类型标识,当交易包含该组网交易类型标识时,就表明该交易用于组建新的区块链子网,即该交易为组建区块链子网的交易。区块链平台代码可以包含相关的用于组建区块链子网的处理逻辑,使得运行该区块链平台代码的第一区块链节点在执行交易时,如果发现该交易中包含上述的组网 交易类型标识,且第一区块链节点对应的节点成员的身份信息被包含于该交易中的配置信息中,可以基于上述处理逻辑来触发部署第一区块链节点的节点设备生成包含该配置信息的创世块并启动第二区块链节点,由第二区块链节点加载该创世块,以形成为区块链子网中的区块链节点。
节点设备通过在进程中创建一个运行区块链平台代码的实例,实现在该节点设备上部署一区块链节点。对于第一区块链节点而言,由节点设备在上述进程中创建运行区块链平台代码的第一实例而形成。类似地,对于第二区块链节点而言,由节点设备在上述进程中创建运行区块链平台代码的第二实例而形成。例如,节点设备可首先在进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可在上述进程中创建第二实例,该第二实例区别于上述的第一实例,并由该第二实例形成区块链子网中的第二区块链节点。当第一实例与第二实例位于同一进程时,由于不涉及跨进程交互,可降低对第二区块链节点的部署难度、提高部署效率。当然,第二实例也可能与第一实例分别处于节点设备上的不同进程中,本说明书并不对此进行限制;例如,节点设备可在第一进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可启动区别于第一进程的第二进程,并在该第二进程中创建第二实例,该第二实例区别于上述的第一实例,进而由该第二实例形成区块链子网中的第二区块链节点。
通过上述方式,可以在区块链主网上创建出区块链子网。以图5为例,subnet0原本包含nodeA~nodeE,而在subnet0的基础上可以组建出subnet1,该subnet1包含nodeA1~nodeD1,且nodeA与nodeA1、nodeB与nodeB1、nodeC与nodeC1、nodeD与nodeD1分别部署在同一节点设备上。类似地,还可以在subnet0上组建出subnet2或更多的区块链子网,其中subnet2包含nodeA2、nodeB2、nodeC2和nodeE2,且nodeA与nodeA1、nodeA2,nodeB与nodeB1、nodeB2,nodeC与nodeC1、nodeC2,nodeD与nodeD1,nodeE与nodeE2分别部署在同一节点设备上。以及,可以将subnet1、subnet2等作为新的区块链主网,并在此基础上进一步组建出区块链子网,其过程与subnet1或subnet2的组建相似,此处不再赘述。
在上述如图4所示的实施例中,实际上是从整个区块链系统的角度来描述了本说明书的组建区块链子网的过程,而在该过程中,并非所有的节点成员都参与了区块链子网,接下来将结合图6,从参与区块链子网的主网节点及其所处的节点设备的角度,对本说明书的技术方案进行描述。容易理解的是,图6所示的实施例与图4所示的实施例并不存在本质上的差异,前文针对图4所示实施例的描述,均适用于图6所示的实施例。
图6是一示例性实施例提供的另一种组建区块链子网的方法的流程图。如图6所示,该方法可以包括以下步骤:步骤602,区块链主网中的第一区块链节点获取组建区块链子网的交易,所述交易包含所述区块链子网的配置信息,所述配置信息包括参与组建所述区块链子网的节点成员的身份信息。
步骤604,第一区块链节点执行所述交易以透出所述配置信息。
步骤606,在所述配置信息包含第一区块链节点对应的节点成员的身份信息时,部署第一区块链节点的节点设备基于包含所述配置信息的创世块启动属于所述区块链子网的第二区块链节点。
如前所述,所述组建区块链子网的交易包括调用合约的交易。
如前所述,所述合约包括创世合约或系统合约。
如前所述,所述合约的执行结果包括所述配置信息,部署第一区块链节点的节点设备通过消息机制获得所述配置信息,并根据获得的配置信息生成所述创世块;或者,所述合约的执行结果包括所述创世块,部署第一区块链节点的节点设备通过消息机制获得所述创世块。
如前所述,所述合约执行后生成的收据中包含与组建新的区块链子网相关的组网 事件;所述部署第一区块链节点的节点设备通过消息机制获得所述配置信息或所述创世块,包括:第一区块链节点监听生成的收据,并在监听到所述组网事件且所述组网事件的内容表明第一区块链节点属于所述节点成员的情况下,触发部署第一区块链节点的节点设备获取所述组网事件包含的所述配置信息或所述创世块;或者,部署第一区块链节点的节点设备监听生成的收据,并在监听到所述组网事件且所述组网事件的内容表明第一区块链节点属于所述节点成员的情况下,获取所述组网事件包含的所述配置信息或所述创世块。
如前所述,所述组网事件包括:所述收据中的主题名称包含预定义的组网事件标识的事件。当所述组网事件的内容包含下述标识时,表明所述组网事件与组建新的区块链子网相关:希望组建的区块链子网的网络标识,且所述网络标识区别于已有区块链子网;或者,预定义的新建网络标识,所述新建网络标识表明所述组网事件用于组建新的区块链子网。
如前所述,所述交易包括组网交易类型标识,所述组网交易类型标识表明所述交易用于组建新的区块链子网。
如前所述,所述组建区块链子网的交易由所述区块链主网的管理员发起;或者,所述组建区块链子网的交易由所述区块链主网的普通用户发起。
如前所述,所述配置信息还包括下述至少之一:所述区块链子网的网络标识、所述区块链子网的管理员的身份信息、针对区块链平台代码的属性配置。
如前所述,所述区块链主网与所述区块链子网的管理员相同或不同。
如前所述,针对区块链平台代码的属性配置包括下述至少之一:代码版本号、是否需要共识、共识算法类型、区块大小。
如前所述,所述节点设备启动第二区块链节点包括:所述节点设备创建运行区块链平台代码的第二实例,第二实例区别于所述节点设备上运行所述区块链平台代码且对应于第一区块链节点的第一实例。
如前所述,第一区块链节点生成的区块与第二区块链节点生成的区块分别存入所述节点设备上的不同存储。
如前所述,第一区块链节点与第二区块链节点分别使用的存储之间相互隔离。
如前所述,所述存储为数据库。
如前所述,所述区块链主网为底层区块链网络;或者,所述区块链主网为其他区块链网络的子网。
此处,提供一种为业务流程合约调度计算服务的方法。该方法通常是在一个区块链网络中实现的,而该区块链网络可以是常见的区块链网络,也可以是前文所述的区块链系统中的主网或子网。
图7是一种为业务流程合约调度计算服务的方法的流程示意图,包括以下步骤:S700:针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程。
本文所述的节点设备,可以是单个设备或者设备集群。而本文所述的区块链网络,可以是公有链网络或者联盟链网络。
区块链网络上部署了业务流程合约,业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点。
业务流程合约是用于在区块链网络中实现某个业务流程的智能合约。在业务流程的推进过程中,通常会涉及若干计算任务,而根据实际情况,不一定全部节点都会参与某个计算任务,换言之,参与每个计算任务的节点可能是区块链网络的全部节点,也可能是区块链网络的部分节点。
在有些实施例中,业务流程合约中的各计算任务之间可以是相对独立的,即每个 计算任务的输入并不依赖于其他计算任务的输出。
而在有些实施例中,所述业务流程合约中定义的各计算任务组成有向图结构,所述图结构中各结点与各计算任务一一对应。对于每个计算任务,若该计算任务有入边,则该入边所连接的其他计算任务的计算输出,是该计算任务的输入;若该计算任务没有入边,则该计算任务不需要输入或输入由所述交易指定;若该计算任务有出边,则该出边所连接的其他计算任务的输入,是该计算任务的输出。
区块链网络中的每个节点对应的节点设备上通常运行着一个独立于节点的调度进程,调度进程用于调度计算服务进程。所谓计算服务进程,是指为计算任务提供计算服务的进程,计算服务进程自身具有计算能力,也独立于节点。通常而言,在每个节点对应的节点设备上部署不同计算类型对应的计算功能代码,当需要创建某个计算类型对应的计算服务进程时,基于该计算类型对应的计算功能代码,创建计算服务进程。
调度进程与计算服务进程,都是链外的进程,并不依赖于节点的运行状态。
通常而言,在节点设备上部署节点时,就会一并创建一个调度进程,并且,一并在节点设备上部署若干计算类型的计算功能代码。在实际应用中,区块链网络不同成员的节点设备上部署的计算功能代码的计算类型可以不一致,这可以取决于不同成员可对接的数据源以及不同成员的计算能力而定。例如,对于联盟链网络而言,金融机构的节点设备上通常可以部署用于计算信用风险的计算类型的计算功能代码,而物流机构的节点设备上通常可以部署用于计算物流路线的计算类型的计算功能代码。
同一成员的节点设备上可以创建多个同一计算类型的计算服务进程。同一计算类型的计算服务进程的功能也可以不完全相同。这是因为,在实际应用中,有的计算服务进程可以提供通用的计算能力,这种计算服务进程可以直接执行涉及通用计算的计算任务;而有的计算服务进程可以提供针对具体业务场景的计算能力,相当于是业务场景与通用计算能力的结合,而计算服务进程的类型划分通常是根据通用计算能力而定的,因此可能会出现同一节点设备上部署的同一计算类型的多个计算服务进程针对不同业务场景,能力不完全一致。也就是说,同一计算类型对应的不同计算服务进程,是在该计算类型对应的计算功能代码的基础上,结合不同的业务场景配置创建的,用于执行不同业务场景下的计算任务。
一般而言,区块链网络中可以部署一个或多个业务流程合约,不同业务流程合约所针对的业务场景不同,因此,即便是同一类型的计算代码,也可以集合不同业务流程合约中指定的业务场景配置,创建服务于不同业务流程合约的不同计算服务进程。
而对于计算服务进程的创建时机,主要有以下几种情况:1、在有些实施例中,可以在区块链网络中部署业务流程合约之前,就预先基于每个节点对应的节点设备上部署的若干计算类型的计算功能代码,创建(也意味着启动)若干计算类型的计算服务进程。如此,区块链网络部署业务流程合约之后,调度进程将已经运行的计算服务进行调度,为业务流程合约中的至少部分计算任务分配所占用的计算服务进程。此处的“占用”,是指计算服务进程专用于为计算任务提供计算服务,可以设定一个计算服务进程被一个计算任务占用之后,其他计算任务就不能再占用该计算服务进程,而未被占用的计算服务进程处于可占用状态,可视为处于闲置。也可以设定N(大于1)个计算任务可以占用同一个计算服务进程,如此,只要同时占用该计算服务进程的计算任务的数量未达到N,该计算服务就处于可占用状态。
当然,如果网络中部署了很多业务流程合约,某个计算类型的计算服务进程已经都被占用,那么当需要为一个新部署的业务流程合约调度该计算类型的计算服务进程时,可以临时再创建新的该计算类型的计算服务。
2、在有些实施例中,可以在区块链网络中部署了业务流程合约之后,调度流程根据业务流程合约的内容,并基于各计算类型的计算功能代码,创建服务于该业务流程合约的计算服务进程。
3、在有些实施例中,调度进程可以判断对应节点设备上是否运行着至少一个对应于该计算类型、处于可占用状态的计算服务进程;若判断结果为是,则将其中一个计算服务进程调度为该计算任务占用的计算服务进程;若判断结果为否,则在满足设备限制条件的情况下,基于对应节点设备上部署的该计算类型对应的基础计算功能代码,创建一个对应于该计算类型、处于可占用状态的计算服务进程,并将启动的该计算服务进程调度为该计算任务占用的计算服务进程。
计算服务进程处于可占用状态,可以理解为:计算服务进程未被任一计算任务占用;或者,计算服务进程未被N个计算任务同时占用,N为可占用该计算服务进程的计算任务的数量最大值。
其中,设备限制条件可为:对应节点设备上运行的计算服务进程的数量不超过数量上限;数量上限是根据对应节点设备的性能水平确定的。
进一步,在为某个计算任务创建计算服务进程时,若该计算任务指定了业务场景配置,则在对应节点设备上部署的该计算类型对应的计算功能代码的基础上,结合该计算任务指定的业务场景配置,创建一个对应于该计算类型、处于可占用状态的计算服务进程;若该计算任务未指定业务场景配置,则基于对应节点设备上部署的该计算类型对应的基础计算功能代码,创建一个对应于该计算类型、处于可占用状态的计算服务进程。
4、在有些实施例中,可以每当区块链网络接收到一个调用业务流程合约的业务交易时,临时为业务流程合约中至少部分计算任务调度计算服务进程。即针对任一计算任务,该计算任务占用的计算服务进程,是在所述业务流程合约被所述业务交易调用之后创建的。待到该业务交易处理完成之后,再解除业务流程合约对这些计算服务进程的占用关系。如此,可以充分利用节点设备上的计算服务进程资源。
5、在有些实施例中,调度进程可以在每当要执行业务流程合约中的某个计算任务时,临时为该计算任务调度计算服务进程,该计算任务执行完成之后,解除该计算任务对该计算服务进程的占用。即针对所述业务流程合约中定义的每个计算任务,参与该计算任务的节点对应的调度进程,在获取到该计算任务占用的计算服务进程返回的计算结果之后,解除该计算任务对该计算服务进程的占用状态。如此,可以进一步提升对节点设备上的计算服务进程资源的利用效率。
在有些实施例中,针对任一计算任务,若参与该计算任务的节点不止一个,则参与该计算任务的各节点分别对应的该计算任务占用的计算服务进程,通过协作方式实现该计算任务。此处的协作方式具体可以是多方安全计算的方式。在实际应用中,参与同一计算任务的各节点对应的成员可能需要贡献自己收集的数据参与计算,而出于数据安全性的考虑,参与同一计算任务的各节点对应的成员需要在数据不出域的前提下,利用各自节点设备上部署的同一计算类型的计算服务进程,彼此协作来完成该计算任务。另外,上述的协作方式也可以是其他需要多方协作参与的方式。
图8是本说明书提供的一种基于链外计算服务的业务执行方法的流程示意图,包括以下步骤。
S800:所述区块链网络中每个节点获取调用所述业务流程合约的业务交易。
下文在对图7所示方法进行说明时,不再关注计算服务进程的创建时机。总之,在开始执行步骤S800之前,针对所述业务流程合约中定义的至少部分计算任务(中的每个计算任务),运行参与该计算任务的节点的节点设备上还运行:该计算任务占用的计算服务进程以及用于调度计算服务进程的调度进程。
业务交易通常指定了业务参数,作为业务流程合约的输入。
S802:所述区块链网络中每个节点根据所述业务交易,执行所述业务流程合约:针对所述业务流程合约中定义的至少部分计算任务,若确定满足该计算任务的开始条件,则触发针对该计算任务的请求事件。
此处的“至少部分计算任务”,可以是业务流程合约中的全部计算任务,也可以是部 分计算任务。而步骤S802中,是针对至少部分计算任务中的每个计算任务而言的。节点根据交易执行业务流程合约的过程,就是根据交易执行业务流程合约中各计算任务的过程。对于至少部分占用了链外计算服务进程的计算任务,节点一旦判断满足该计算任务的开始条件,则基于合约的事件消息机制,触发针对该计算任务的请求事件。
其中,该计算任务的开始条件可以根据实际需要指定。在有些实施例中,如果业务流程合约中各计算任务在逻辑上可以组成前文所述的有向图结构,任一计算任务的开始条件可以是该计算任务的入边所连接的每个其他计算任务皆已完成。若该计算任务需要输入,则针对该计算任务的请求事件的消息包含该计算任务的输入。若判断不满足该计算任务的开始条件,则节点不会触发针对该计算任务的请求事件。
S804:参与该计算任务的每个节点对应的调度进程在监听到该请求事件之后,调用该计算任务占用的计算服务进程。
对于未参与该计算任务的节点对应的调度进程,在监听到该请求事件之后,可以不作处理,将该请求事件的消息进行丢弃。
在有些实施例中,针对任一计算任务,如果有多个节点参与,则分布于不同节点设备上的该计算任务占用的各计算服务进程,可以通过协作方式执行该计算任务。
S806:该节点对应的调度进程获取该计算服务进程返回的计算结果。
S808:该节点对应的调度进程基于该计算结果,将调用所述业务流程合约的计算结果交易提交给所述区块链网络。
该计算结果交易可以将该计算结果带入到业务流程合约中,以便将业务流程推进到接下来的计算任务。
通过图7和图8所示的方法流程,节点执行业务流程合约的过程中,并不需要直接执行每个计算任务,而是将至少部分计算任务交给独立于节点的计算服务进程来直接执行,从而减弱了业务流程的推进效率对节点运行状态的依赖性,即便节点运行异常,也不容易拖延业务流程的推进。即便某个计算任务执行异常,也可能不需要节点进行异常修复,也不容易影响节点的运行状态。
在实际应用中,有些不具有管理员权限的用户可能需要借助区块链系统中部分成员的节点设备的计算能力,实现用户自己的一些业务流程,因此,这些用户通常需要请求在区块链系统中创建一个区块链子网。为此,本说明书提供一种区块链子网的创建方法,用于实现不具有管理员权限的用户发起区块链子网,该方法包括:1、各主网节点分别获取调用本网治理合约的子网创建交易。
其中,每个主网节点上可以部署本网治理合约与子网管理合约。本网治理合约,是指用于治理本网内发生的各事项的智能合约。此处的“本网”是指智能合约所部署的区块链网络本身。除了主网之外,任一区块链子网也可以部署本网治理合约,用于对该区块链子网内发生的各事项进行治理。
此处的治理可包括对本网创建子网的行为进行治理,具体涉及针对本网创建子网的事项进行投票的机制。除了可针对子网创建的事项进行投票以外,在有些实施例中,还可针对本网中节点增删、本网中合约部署、本网中已部署合约的更新等事项进行投票。
子网管理合约是指用于管理本网的下一级子网的智能合约。此处的管理可包括创建下一级子网,还可包括关闭下一级子网、向下一级子网中增加节点、从下一级子网中删除节点等。不具有管理员权限的用户可通过自己的客户端构建子网创建交易并提交给主网,子网创建交易指定了子网配置信息。该子网配置信息包括多个参与子网的成员的身份信息,以便指示主网应在哪些成员的节点设备上创建新的子网节点从而组成子网。并且,子网创建交易还需要指定调用的合约为主网中部署的本网治理合约,以便本网治理合约触发针对子网创建事项的投票机制。
2、各主网节点执行本网治理合约:触发针对该子网创建交易的投票事件。
3、各投票方客户端分别在监听到该投票事件之后,判断是否许可该子网创建交易, 并基于判断结果,向主网提交调用本网治理合约的投票交易。
4、各主网节点继续执行本网治理合约:根据接收到的各投票交易,在确定投票通过的情况下,调用子网管理合约。
智能合约通常支持事件机制,提供一种链内的智能合约与链外进行交互的能力。区块链网络外可以监听到区块链网络内的事件,并响应于监听的事件向区块链网络提交调用智能合约的交易,从而实现响应于智能合约的需求向智能合约提供参数的目的。
各主网节点在根据子网创建交易执行本网治理合约的过程中,会触发针对该子网创建交易的投票事件,投票事件的消息通常包含子网创建交易指定的子网配置信息。各投票方客户端可以监听到投票事件的消息,根据待创建的子网的子网配置信息,判断是否许可该子网创建交易。
投票方的身份可以根据实际需要进行指定。一般而言,各投票方可以是具有管理员权限的各用户,管理员用户可以是成员自己,也可以是成员授权的某个其他用户。
从是否是成员的角度,各投票方的身份可以包括以下情况:所述系统的全部成员;或者,所述系统的部分成员;或者,所述系统的部分成员与至少一个非成员;或者,所述系统的全部成员与至少一个非成员;或者,多个非成员。
投票方客户端判断是否许可该子网创建交易的方式,具体可以是将相应的子网配置信息展示给投票方,并接收投票方输入的指令(同意或不同意);也可以是根据预置的判断规则,判断是否许可。每个投票方客户端将判断结果封装到投票交易中,并将投票交易提交给主网。投票交易也需要调用本网治理合约。
每个主网节点基于执行本网治理合约的过程中,接收到每个投票方客户端提交的投票交易,统计投票结果,如果投票结果表征通过(即同意构建子网),则通过合约间相互调用的方式,通过本网治理合约调用子网管理合约,将子网配置信息通过合约间接口传递给子网治理合约,以便通过子网管理合约进行子网创建。
5、各主网节点执行子网管理合约:根据该子网配置信息,触发子网创建事件。
6、每个参与子网的成员的节点设备上的主网节点,在监听到该子网创建事件之后,部署子网节点。
主网节点执行调用的子网管理合约的过程中,继续利用事件机制,触发子网创建事件,该事件的消息包含子网配置信息。每个主网节点监听到子网创建事件,可以判断子网配置信息中是否包含本设备对应的成员的身份信息,如果不包含,则无需处理,如果包含,则在本设备部署子网节点。
在有些实施例中,每个参与子网的成员的节点设备上的主网节点,在部署子网节点时,可以将该子网配置信息写入子网节点维护的区块链的创世块中。
在实际应用中,子网创建之后,请求创建子网的用户往往后续还会逐渐在子网中部署若干业务流程合约。而出于安全性考虑,区块链系统中的各成员希望用户在请求创建子网时,就对后续将要部署在子网中的业务流程合约进行预注册,以方便安全管控。在子网创建之后,只允许用户在子网中部署的预注册过的业务流程合约。
为此,在有些实施例中,子网创建交易指定的子网配置信息还可以包括合约预注册信息;该合约预注册信息包括允许部署在创建好的子网中的一个或多个业务流程合约的明文或者合约哈希。如果预注册信息中包含的是合约哈希,则可以实现用户不将合约明文暴露给主网,仅会暴露给创建好的子网的效果。合约预注册信息还可以包括允许部署在创建好的子网中的一个或多个业务流程合约的合约标识。另外,在合约预注册信息中包括的是合约哈希的情况下,合约预注册信息还可以包括允许部署在创建好的子网中的一个或多个业务流程合约对应的业务流程简介。
在被创建的子网的创世块中包含合约预注册信息的情况下,向该子网中部署业务流程合约的方式可以是:被创建的区块链子网中的各子网节点分别获取业务流程合约部署交易;验证所述业务流程合约部署交易指定的业务流程合约的合约哈希,是否记录于 创世块中的合约预注册信息中;若是,则部署所述业务流程部署交易指定的业务流程合约;若否,则拒绝部署所述业务流程部署交易指定的业务流程合约。
在有些实施例中,在创建区块链子网之后,可以在区块链子网中部署本网治理合约。后续需要在区块链子网中部署业务流程合约时,可以向区块链子网提交调用本网智能合约的业务流程合约部署交易,本网治理合约基于前文所述的投票机制,触发投票决定是否可以在区块链子网中部署业务流程合约部署交易指定的业务流程合约。各投票方可以参考区块链子网的创世块中的合约预注册信息来投票。
在图8所示的方法中,区块链网络的创世块中可以包含合约预注册信息,所述合约预注册信息包括:允许部署在所述区块链网络的一个或多个业务流程合约的合约哈希。如此,为所述区块链网络部署业务流程合约的方式具体可以是,区块链网络的节点获取业务流程合约部署交易;验证所述业务流程合约部署交易指定的业务流程合约的合约哈希,是否记录于创世块中的合约预注册信息中;若是,则部署所述业务流程部署交易指定的业务流程合约;若否,则拒绝部署所述业务流程部署交易指定的业务流程合约。
在有些实施例中,主网的下一级子网也可以部署自己的本网治理合约与子网管理合约。也就是说,类似于主网创建下一级子网的流程,子网也可以创建更自己的下一级子网。具体而言:对于所述系统中任一区块链子网,该区块链子网的各子网节点分别获取调用本网治理合约的子网创建交易;该子网创建交易指定了子网配置信息,该子网配置信息包括:多个参与子网的成员的身份信息;所述各子网节点执行本网治理合约:触发针对该子网创建交易的投票事件;各投票方客户端分别在监听到该投票事件之后,判断是否许可该子网创建交易,并基于判断结果,向该区块链子网提交调用本网治理合约的投票交易;所述各子网节点继续执行本网治理合约:根据接收到的各投票交易,在确定投票通过的情况下,调用子网管理合约;所述各子网节点执行子网管理合约:根据该子网配置信息,触发子网创建事件;每个参与子网的成员的节点设备上的子网节点,在监听到该子网创建事件之后,部署子网节点。
在子网创建下一级子网的实施例中,创建的下一级子网的创世块中同样可以包含合约预注册信息,允许后续在创建的下一级子网中部署的业务流程合约同样需要与合约预注册信息匹配。如何在创建的下一级子网中部署业务流程合约的实施例可以参照前文理解,此处不再赘述。
本说明书实施例提供的另一种区块链子网的创建方法的流程示意图,包括以下步骤:1、各主网节点分别获取调用本网治理合约的子网创建交易。
每个主网节点上部署了本网治理合约、子网管理合约与业务流程管理合约。
业务流程管理合约用于记录创建的子网与合约预注册信息之间的对应关系,并可提供对应关系查询功能。
该子网创建交易指定了子网配置信息,该子网配置信息包括:多个参与子网的成员的身份信息与合约预注册信息;该合约预注册信息包括:允许部署在创建好的子网中的一个或多个业务流程合约的合约哈希。
此方法与之前的子网的创建方法的主要区别在于,主网节点上还部署了业务流程管理合约,在处理子网创建交易的流程上,本网治理合约不再调用子网管理合约,而是在确定投票通过的情况下调用流程管理合约,将子网配置信息传递给流程管理合约,进而由流程管理合约调用子网管理合约(将子网配置信息进一步传递给子网管理合约)进行子网创建,并且由流程管理合约记录创建的子网与合约预注册信息之间的对应关系。
2、各主网节点执行本网治理合约:触发针对该子网创建交易的投票事件。
3、各投票方客户端分别在监听到该投票事件之后,判断是否许可该子网创建交易,并基于判断结果,向主网提交调用本网治理合约的投票交易。
4、各主网节点继续执行本网治理合约:根据接收到的各投票交易,在确定投票通过的情况下,调用业务流程管理合约。
5、各主网节点执行业务流程管理合约:调用子网管理合约,并且,保存待创建的子网的网络标识与该合约预注册信息之间的对应关系。
在有些实施例中,由流程管理合约为待创建的子网分配网络标识,并建立网络标识与合约预注册信息之间的对应关系。在另一些实施例中,由子网管理合约为待创建的子网分配子网标识,这种情况下,子网管理合约需要在被流程管理合约调用后,再将子网标识返回给流程管理合约。
6、各主网节点执行子网管理合约:根据该子网配置信息,触发子网创建事件。
7、每个参与子网的成员的节点设备上的主网节点,在监听到该子网创建事件之后,部署子网节点。
用户可以查询主网节点的业务流程合约中记录的,每个子网对应的合约预注册信息,了解允许在主网创建的每个子网上部署哪些合约。具体的,各主网节点分别获取调用流程管理合约的查询交易;该查询交易指定了主网所创建的子网的网络标识;各主网节点执行流程管理合约:查询该网络标识对应的合约预注册信息,将查询到的合约预注册信息返回给提交该查询交易的客户端。
主网创建的子网也可以进一步创建下一级子网,具体的:任一区块链子网的各子网节点分别获取调用本网治理合约的子网创建交易;该子网创建交易指定了子网配置信息,该子网配置信息包括:多个参与子网的成员的身份信息与合约预注册信息;该合约预注册信息包括:允许部署在创建好的子网中的一个或多个业务流程合约的合约哈希;所述各子网节点执行本网治理合约:触发针对该子网创建交易的投票事件;各投票方客户端分别在监听到该投票事件之后,判断是否许可该子网创建交易,并基于判断结果,向该区块链子网提交调用本网治理合约的投票交易;所述各子网节点继续执行本网治理合约:根据接收到的各投票交易,在确定投票通过的情况下,调用业务流程管理合约;所述各子网节点执行业务流程管理合约:调用子网管理合约,并且,保存待创建的子网的网络标识与该合约预注册信息之间的对应关系;所述各子网节点执行子网管理合约:根据该子网配置信息,触发子网创建事件;每个参与子网的成员的节点设备上的子网节点,在监听到该子网创建事件之后,部署子网节点。
在实际应用中,可以仅在主网上部署一个智能合约,该智能合约集成了前文所述的本网治理合约、子网管理合约、业务流程管理合约的功能。这样的方法包括:
1、各主网节点分别获取调用智能合约的子网创建交易。该子网创建交易指定了子网配置信息,该子网配置信息包括:多个参与子网的成员的身份信息;
2、各主网节点执行智能合约:触发针对该子网创建交易的投票事件。
3、各投票方客户端分别在监听到该投票事件之后,判断是否许可该子网创建交易,并基于判断结果,向主网提交调用本网治理合约的投票交易。
4、各主网节点继续执行智能合约:根据接收到的各投票交易,在确定投票通过的情况下,根据该子网配置信息,触发子网创建事件。
5、每个参与子网的成员的节点设备上的主网节点,在监听到该子网创建事件之后,部署子网节点。
该子网配置信息还可包括合约预注册信息;该合约预注册信息包括允许部署在创建好的子网中的一个或多个业务流程合约的合约哈希。
各主网节点执行智能合约过程中,还可以保存待创建的子网的网络标识与该合约预注册信息之间的对应关系。
各主网节点分别获取调用智能合约的查询交易;该查询交易指定了主网所创建的子网的网络标识;各主网节点执行智能合约:查询该网络标识对应的合约预注册信息,将查询到的合约预注册信息返回给提交该查询交易的客户端。
另外,本文提供一种为业务流程合约调度计算服务的装置,区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指 定了参与每个计算任务的至少一个节点;所述方法应用于每个节点对应的节点设备上还运行的调度进程,所述装置包括:调度模块,针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
本文提供一种区块链网络,所述区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;每个节点对应的节点设备上还运行的独立于节点的调度进程,针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
本文还提供一种区块链网络,所述区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;针对所述业务流程合约中定义的至少部分计算任务,运行参与该计算任务的节点的节点设备上还运行:该计算任务占用的计算服务进程以及用于调度计算服务进程的调度进程;所述区块链网络中每个节点,获取调用所述业务流程合约的业务交易,并根据所述业务交易,执行所述业务流程合约:针对所述至少部分计算任务,若自身参与该计算任务,且满足该计算任务的开始条件,则触发针对该计算任务的请求事件;每个节点对应的调度进程,在监听到该请求事件之后,调用该计算任务占用的计算服务进程;获取该计算服务进程返回的计算结果,并基于该计算结果,将调用所述业务流程合约的计算结果交易提交给所述区块链网络。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本说明书时可把各单元的功能在同一个或多个软件和/或硬件中实现。本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境 中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (14)

  1. 一种为业务流程合约调度计算服务的方法,区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;所述方法应用于每个节点对应的节点设备上还运行的调度进程,所述方法包括:
    针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;
    其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
  2. 如权利要求1所述方法,所述区块链网络是由多个成员参与的区块链系统中的任一区块链网络;所述系统在硬件层面包括每个成员的节点设备,每个成员的节点设备上部署至少一个节点,同一成员的节点设备上部署的不同节点属于不同区块链网络;所述系统在软件层面具有以区块链主网为根结点、各个区块链子网分别为其他结点的树形结构。
  3. 如权利要求1所述方法,同一计算类型对应的不同计算服务进程,是在该计算类型对应的计算功能代码的基础上,结合不同的业务场景配置创建的,用于执行不同业务场景下的计算任务。
  4. 如权利要求1所述方法,将对应节点设备上运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程,包括:
    判断对应节点设备上是否运行着至少一个对应于该计算类型、处于可占用状态的计算服务进程;
    若判断结果为是,则将其中一个计算服务进程调度为该计算任务占用的计算服务进程;
    若判断结果为否,则在满足设备限制条件的情况下,基于对应节点设备上部署的该计算类型对应的基础计算功能代码,创建一个对应于该计算类型、处于可占用状态的计算服务进程,并将启动的该计算服务进程调度为该计算任务占用的计算服务进程。
  5. 如权利要求4所述方法,所述业务流程合约中定义的各计算任务中的一个或多个计算任务,指定了业务场景配置;
    基于对应节点设备上部署的该计算类型对应的基础计算功能代码,启动一个对应于该计算类型、处于可占用状态的计算服务进程,包括:
    若该计算任务指定了业务场景配置,则在对应节点设备上部署的该计算类型对应的计算功能代码的基础上,结合该计算任务指定的业务场景配置,创建一个对应于该计算类型、处于可占用状态的计算服务进程;
    若该计算任务未指定业务场景配置,则基于对应节点设备上部署的该计算类型对应的基础计算功能代码,创建一个对应于该计算类型、处于可占用状态的计算服务进程。
  6. 如权利要求4所述方法,所述设备限制条件,包括:对应节点设备上运行的计算服务进程的数量不超过数量上限;所述数量上限是根据对应节点设备的性能水平确定的。
  7. 如权利要求1所述方法,计算服务进程处于可占用状态,包括:
    计算服务进程未被任一计算任务占用;
    或者
    计算服务进程未被N个计算任务同时占用,N为可占用该计算服务进程的计算任务的数量最大值,N大于1。
  8. 如权利要求1所述方法,针对任一计算任务,若参与该计算任务的节点不止一个,则参与该计算任务的各节点分别对应的该计算任务占用的计算服务进程,通过协作 方式实现该计算任务。
  9. 如权利要求1所述方法,所述区块链网络的创世块中包含合约预注册信息,所述合约预注册信息包括:允许部署在所述区块链网络的一个或多个业务流程合约的合约哈希。
  10. 如权利要求9所述方法,为所述区块链网络部署业务流程合约,包括:
    所述区块链网络的节点获取业务流程合约部署交易;
    验证所述业务流程合约部署交易指定的业务流程合约的合约哈希,是否记录于创世块中的合约预注册信息中;
    若是,则部署所述业务流程部署交易指定的业务流程合约。
  11. 如权利要求1所述方法,节点对应的节点设备,包括:单个设备或者设备集群。
  12. 如权利要求1所述方法,所述区块链网络为公有链网络或联盟链网络。
  13. 一种为业务流程合约调度计算服务的装置,区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;所述方法应用于每个节点对应的节点设备上还运行的调度进程,所述装置包括:
    调度模块,针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;
    其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
  14. 一种区块链网络,所述区块链网络上部署了业务流程合约,所述业务流程合约中定义了用于实现业务流程的每个计算任务,以及指定了参与每个计算任务的至少一个节点;
    每个节点对应的节点设备上还运行的独立于节点的调度进程,针对所述业务流程合约中定义的至少部分计算任务,在确定对应节点参与该计算任务的情况下,根据该计算任务的计算类型,将对应节点设备上还运行的一个对应于该计算类型、处于可占用状态的计算服务进程,调度为该计算任务占用的计算服务进程;
    其中,所述区块链网络在执行所述业务流程合约的过程中,通过调度进程调用每个计算任务占用的计算服务进程以执行该计算任务。
PCT/CN2022/093809 2021-06-02 2022-05-19 为业务流程合约调度计算服务的方法 WO2022252996A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110611549.4 2021-06-02
CN202110611549.4A CN113067898B (zh) 2021-06-02 2021-06-02 为业务流程合约调度计算服务的方法

Publications (1)

Publication Number Publication Date
WO2022252996A1 true WO2022252996A1 (zh) 2022-12-08

Family

ID=76568501

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/093809 WO2022252996A1 (zh) 2021-06-02 2022-05-19 为业务流程合约调度计算服务的方法

Country Status (2)

Country Link
CN (1) CN113067898B (zh)
WO (1) WO2022252996A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113067898B (zh) * 2021-06-02 2021-08-10 支付宝(杭州)信息技术有限公司 为业务流程合约调度计算服务的方法
CN117940904A (zh) * 2021-09-30 2024-04-26 西门子股份公司 工作流操作的方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200028691A1 (en) * 2018-07-20 2020-01-23 Honeywell International Inc. System and method for a blockchain based automated certifiable workflow process
CN111066047A (zh) * 2019-06-27 2020-04-24 阿里巴巴集团控股有限公司 实现基于区块链的工作流
CN112000454A (zh) * 2020-08-27 2020-11-27 平安国际智慧城市科技股份有限公司 一种多媒体数据的处理方法及设备
CN113067898A (zh) * 2021-06-02 2021-07-02 支付宝(杭州)信息技术有限公司 为业务流程合约调度计算服务的方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6827327B2 (ja) * 2017-01-05 2021-02-10 株式会社日立製作所 分散コンピューティングシステム
CN108804209A (zh) * 2017-05-05 2018-11-13 中思博安科技(北京)有限公司 智能合约的调度方法及装置
CN111782338B (zh) * 2018-12-12 2024-05-03 创新先进技术有限公司 一种基于区块链智能合约的数据处理方法及系统
US11416791B2 (en) * 2019-02-22 2022-08-16 American Express Travel Related Services, Inc. Optimizing user task schedules in a customer relationship management platform
CN111226199B (zh) * 2019-08-27 2022-02-18 创新先进技术有限公司 用于基于区块链的通知的系统和方法
US11645594B2 (en) * 2019-08-28 2023-05-09 The Boeing Company Real-time optimization of aircraft manufacturing task management
CN110543354B (zh) * 2019-09-05 2023-06-13 腾讯科技(上海)有限公司 任务调度方法、装置、设备及存储介质
CN111400008B (zh) * 2020-03-13 2023-06-02 北京旷视科技有限公司 计算资源调度方法、装置及电子设备
CN112003903A (zh) * 2020-07-29 2020-11-27 北京小米松果电子有限公司 一种集群任务调度方法、装置及存储介质
CN111857892B (zh) * 2020-09-22 2020-12-18 支付宝(杭州)信息技术有限公司 通过区块链进行业务处理的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200028691A1 (en) * 2018-07-20 2020-01-23 Honeywell International Inc. System and method for a blockchain based automated certifiable workflow process
CN111066047A (zh) * 2019-06-27 2020-04-24 阿里巴巴集团控股有限公司 实现基于区块链的工作流
CN112000454A (zh) * 2020-08-27 2020-11-27 平安国际智慧城市科技股份有限公司 一种多媒体数据的处理方法及设备
CN113067898A (zh) * 2021-06-02 2021-07-02 支付宝(杭州)信息技术有限公司 为业务流程合约调度计算服务的方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FAN JUN; LI RU; LI SHUO: "Research on Task Scheduling Strategy: Based on Smart Contract in Vehicular Cloud Computing Environment", 2018 1ST IEEE INTERNATIONAL CONFERENCE ON HOT INFORMATION-CENTRIC NETWORKING (HOTICN), IEEE, 15 August 2018 (2018-08-15), pages 248 - 249, XP033495080, DOI: 10.1109/HOTICN.2018.8605986 *
HE HAIWU: "Survey of Smart Contract Technology and Application Based on Blockchain", JOURNAL OF COMPUTER RESEARCH AND DEVELOPMENT, vol. 55, no. 11, 15 November 2018 (2018-11-15), pages 2452 - 2466, XP055809125 *

Also Published As

Publication number Publication date
CN113067898B (zh) 2021-08-10
CN113067898A (zh) 2021-07-02

Similar Documents

Publication Publication Date Title
CN113067901B (zh) 区块链子网的创建方法
WO2022252996A1 (zh) 为业务流程合约调度计算服务的方法
CN113067904B (zh) 组建区块链子网的方法和区块链系统
CN113067894B (zh) 节点退出区块链子网的方法
CN113067902B (zh) 区块链消息的传输方法及装置
CN113055190B (zh) 针对客户端的访问控制方法
CN113067895B (zh) 组建区块链子网的方法和区块链系统
CN113098982B (zh) 区块链消息的传输方法及装置
CN113067897B (zh) 跨链交互方法及装置
WO2023124746A1 (zh) 跨子网交互的权限控制
CN114363162B (zh) 区块链日志的生成方法及装置、电子设备、存储介质
CN113326290B (zh) 跨网查询控制方法
CN113259120B (zh) 同步节点信息列表的方法
CN113067896B (zh) 区块链子网中加入节点的方法和区块链系统
WO2022252993A1 (zh) 基于链外计算服务的业务执行方法
CN113259117B (zh) 同步节点信息列表的方法
CN113259464B (zh) 组建区块链子网的方法和区块链系统
CN113259118A (zh) 同步节点信息列表的方法
WO2023207076A1 (zh) 区块链子网的组建方法及装置
WO2023185043A1 (zh) 一种可调用资源的分配方法和装置
CN113259236B (zh) 区块链网络间的交易转发方法
CN113259237B (zh) 区块链网络间的交易转发方法
CN113259119B (zh) 区块链消息的分发方法及装置
CN113067774B (zh) 区块链网络间的交易转发方法
CN114363349B (zh) 区块链子网的启动方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22815043

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22815043

Country of ref document: EP

Kind code of ref document: A1