WO2023185043A1 - 一种可调用资源的分配方法和装置 - Google Patents

一种可调用资源的分配方法和装置 Download PDF

Info

Publication number
WO2023185043A1
WO2023185043A1 PCT/CN2022/135203 CN2022135203W WO2023185043A1 WO 2023185043 A1 WO2023185043 A1 WO 2023185043A1 CN 2022135203 W CN2022135203 W CN 2022135203W WO 2023185043 A1 WO2023185043 A1 WO 2023185043A1
Authority
WO
WIPO (PCT)
Prior art keywords
tenant
subtask
node
callable
blockchain
Prior art date
Application number
PCT/CN2022/135203
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 WO2023185043A1 publication Critical patent/WO2023185043A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • 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
    • 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/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method and device for allocating callable resources.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger.
  • some nodes sometimes need to implement small-scale transactions to prevent other nodes from obtaining these transactions and related data. Therefore, a blockchain subnet can be further established based on the blockchain mainnet.
  • the blockchain subnet established on the blockchain mainnet can undertake off-chain computing tasks.
  • the node equipment of each subnet node in the blockchain subnet will contribute computing resources or storage resources to implement off-chain computing tasks.
  • the resources on the node devices are often not ,fully utilized, and flexible resource allocation cannot be ,achieved.
  • the object of the present invention is to provide a method and device for allocating callable resources.
  • a callable resource allocation method is proposed, which is applied to node devices deployed with main network nodes and sub-network nodes.
  • the block where the sub-network node is located The chain subnet is managed by the blockchain mainnet where the mainnet node is located.
  • the node equipment is deployed with multiple callable resources.
  • the blockchain mainnet is deployed with a tenant authority contract, and the tenant authority contract maintains There is a corresponding relationship between each tenant and the multiple callable resources, and the blockchain subnet is deployed with a task contract.
  • the method includes: monitoring subtask events generated by the task contract, where the subtask events include the tenant identification of the first tenant and the description information of the participant node of the first subtask initiated by the first tenant; in the subtask When the network node belongs to the participant node of the first subtask, the first callable resource corresponding to the first tenant among the plurality of callable resources is determined from the tenant permission contract based on the tenant identification of the first tenant. , and call the first callable resource to execute the first subtask.
  • a callable resource allocation device is proposed, which is applied to node equipment deployed with main network nodes and sub-network nodes.
  • the block where the sub-network node is located The chain subnet is managed by the blockchain mainnet where the mainnet node is located.
  • the node equipment is deployed with multiple callable resources.
  • the blockchain mainnet is deployed with a tenant authority contract, and the tenant authority contract maintains There is a corresponding relationship between each tenant and the multiple callable resources, and the blockchain subnet is deployed with a task contract.
  • the device includes: an event listening unit, configured to listen to subtask events generated by the task contract, where the subtask events include a tenant identification of the first tenant and a description of the participant node of the first subtask initiated by the first tenant. Information; a resource calling unit configured to determine, from the tenant rights contract, the first tenant's role in the multi-tasking group based on the tenant identity of the first tenant when the subnet node belongs to the participant node of the first subtask. A corresponding first callable resource among the callable resources is obtained, and the first callable resource is called to execute the first subtask.
  • an electronic device including: a processor; and a memory for storing instructions executable by the processor.
  • the processor implements the method described in the first aspect by running the executable instructions.
  • a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.
  • the resource allocation of multiple tenants in the process of executing off-chain computing tasks using the blockchain subnet as the carrier is managed through the tenant rights contract deployed on the blockchain main network, so that multiple tenants can
  • the computing resources and/or storage resources of the node equipment where each subnet node is located are shared, so that the resources on each node equipment are fully utilized; at the same time, because different callable resources can be configured for different tenants in the tenant permission contract, Therefore, this solution for permission management of callable resources on node devices based on tenant identities can also achieve flexible allocation of callable resources on each node device.
  • Figure 1 is a schematic diagram of establishing a blockchain subnet based on the blockchain main network according to an exemplary embodiment.
  • FIG. 2 is a flow chart of a callable resource allocation method provided by an exemplary embodiment.
  • Figure 3 is a schematic structural diagram of a node device provided in an exemplary embodiment.
  • Figure 4 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • FIG. 5 is a block diagram of a callable resource allocation device provided in an exemplary embodiment.
  • all blockchain nodes in the blockchain network maintain the same block data, which cannot meet the special needs of some nodes.
  • all alliance members i.e., node members within the alliance
  • All alliance members can form a blockchain network. All alliance members have corresponding blockchain nodes in the blockchain network and can pass through the corresponding zones. Blockchain nodes obtain all transactions and related data that occur on the blockchain network. However, in some cases, there may be some alliance members who want to complete some transactions with confidentiality requirements. These alliance members hope that these transactions can be stored on the blockchain or take advantage of other advantages of blockchain technology, and can avoid other Alliance members view these transactions and related data.
  • these alliance members can additionally form a new blockchain network, which is similar to the above-mentioned blockchain network containing all alliance members, building a new blockchain network from scratch requires a large amount of resources, and regardless of The establishment process of the blockchain network or the configuration process after it is built are very time-consuming.
  • the demands among alliance members are often temporary or time-sensitive, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network. .
  • the needs among alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever alliance members change, a new blockchain network may need to be formed, resulting in a loss of resources and time. A lot of waste.
  • the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be established based on the blockchain main network. Then, in a consortium chain scenario such as the above, consortium members can establish the required blockchain subnet based on their own needs based on their own needs after already participating in the blockchain mainnet. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet consumes more resources and takes more time than establishing a completely independent blockchain network. are greatly reduced and the flexibility is extremely high.
  • the process of quickly establishing a blockchain subnet based on the blockchain main network is as follows: Each blockchain node in the blockchain main network obtains the transaction to establish the blockchain subnet respectively, and the transaction includes the configuration information of the blockchain subnet. , the configuration information includes the identity information of the node members participating in the establishment of the blockchain subnet, and each blockchain node in the blockchain main network executes the transaction respectively to reveal the configuration information.
  • the configuration information contains the identity information of the node member corresponding to the first blockchain node
  • the node device deploying the first blockchain node starts the third node belonging to the blockchain subnet based on the genesis block containing the configuration information.
  • Two blockchain nodes Two blockchain nodes.
  • the blockchain main network is subnet0
  • the blockchain nodes included in subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, etc.
  • nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: If nodeA is the administrator and only allows the administrator to initiate transactions to form a blockchain subnet, then nodeA can initiate the above transaction to form a blockchain subnet to subnet0; If nodeE is the administrator and only allows the administrator to initiate transactions to establish a blockchain subnet, then nodeA ⁇ nodeD need to request nodeE, so that nodeE initiates the above-mentioned transaction to establish a blockchain subnet to subnet0; if nodeE is an administrator but allows If an ordinary user initiates a transaction to establish a blockchain subnet, then nodeA ⁇ nodeE can initiate the above-mentioned transaction to establish a blockchain subnet to subnet0.
  • the blockchain node that initiates the transaction to establish the blockchain subnet does not necessarily participate in the formed blockchain subnet.
  • nodeA, nodeB, nodeC and nodeD eventually form the blockchain subnet network, but nodeE can initiate the above-mentioned transaction of forming a blockchain subnet to subnet0, and it is not necessarily nodeA ⁇ nodeD that initiates the transaction of forming 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 established on the basis of other blockchain networks, such as the one in Figure 1 subnet0 can be considered as the blockchain mainnet belonging to the underlying blockchain network type.
  • the blockchain mainnet in this specification can also be a subnet of other blockchain networks.
  • subnet1 is the blockchain mainnet 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.
  • the configuration information can be used to configure the formed blockchain subnet so that the formed blockchain subnet meets the networking requirements. For example, by including the identity information of node members in the configuration information, you can specify which blockchain nodes are included in the formed blockchain subnet.
  • the identity information of node members may include the public key of the node, or other information that can characterize the identity of the node, such as node ID. This specification does not limit this.
  • each blockchain node has one or more corresponding sets of public and private key pairs.
  • the blockchain node holds the private key and the public key is made public and uniquely corresponds to the private key. Therefore, it can be
  • the public key represents the identity of the corresponding blockchain node. Therefore, for blockchain nodes that wish to serve as node members of the blockchain subnet, the public keys of these blockchain nodes can be added to the above-mentioned transaction for forming the blockchain subnet as the identity information of the above-mentioned node members.
  • the above public and private key pairs can be used in the signature verification process.
  • the nodeA1 mentioned above in subnet1 signs the message using its own private key, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key of nodeA1.
  • Perform signature verification on the received message to confirm that the message received does come from nodeA1 and has not been tampered with.
  • the first main network node may be a blockchain node on the blockchain main network that belongs to the node member indicated by the configuration information.
  • the first mainnet node does not directly participate in forming the blockchain subnet and become its node member. Instead, the node device used to deploy the first mainnet node needs to generate the first subnet node. , and the first subnet node becomes a node member in the blockchain subnet.
  • the first mainnet node and the first subnet node correspond to the same blockchain member. For example, in the alliance chain scenario, they correspond to the same alliance chain member, but the first mainnet node belongs to the blockchain mainnet and the first subnet.
  • the node belongs to the blockchain subnet, so that the blockchain members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet are two independent
  • the blockchain network allows the blocks generated by the first main network node and the blocks generated by the first sub-network node to be stored in different storage on the node device (the storage used can be a database, for example), realizing the first
  • the storage used by the main network node and the first subnet node is isolated from each other. Therefore, the data generated by the blockchain subnet will only be synchronized among the node members of the blockchain subnet, so that only those participating in the blockchain main network will be synchronized.
  • the blockchain members of the network cannot obtain the data generated on the blockchain subnet, which realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies the needs of some blockchain members (i.e., the districts participating in the blockchain subnet). Transaction needs between blockchain members).
  • first main network node and the first sub network node are logically divided blockchain nodes. From the perspective of physical equipment, it is equivalent to the above deployment of the first main network node and the first sub network node.
  • the node equipment participates in both the blockchain main network and the blockchain subnet. Since the blockchain main network and the blockchain sub-network are independent of each other, the identity systems of the two blockchain networks are also independent of each other. Therefore, even the first main network node and the first sub-network node can use the exact same public name. key, the two should still be considered different blockchain nodes.
  • nodeA in subnet0 is equivalent to the first main network node, and the node device deploying nodeA generates nodeA1 belonging to subnet1, and nodeA1 is equivalent to the first subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the first subnet node is different from that of the first mainnet node, it will not affect the implementation of the solution in this specification.
  • the node members of the blockchain subnet are not necessarily only some of the node members of the blockchain mainnet.
  • the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network.
  • all blockchain members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other.
  • one type of function can be implemented on the blockchain main network and another type of function can be implemented on the blockchain subnet, so that the two types of functions can be realized.
  • Function data generated by functions 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 identity information for the blockchain platform This manual does not limit the attribute configuration of the code.
  • the network identifier is used to uniquely characterize 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 for example, can be the public key of the node member who is the administrator; among them, the administrators of the blockchain main network and the blockchain subnet can be the same or different.
  • One of the advantages of building a blockchain subnet through the blockchain mainnet is that since the first mainnet node has been deployed on the node device that generates the first subnet node, the area used by the first mainnet node can be The blockchain platform code is reused on the first subnet node, which eliminates the need for repeated deployment of the blockchain platform code and greatly improves the efficiency of building the blockchain subnet.
  • the first subnet node can reuse the attribute configuration adopted on the first main network node; if the configuration information contains the attribute configuration for the blockchain platform code, Attribute configuration, the first subnet node can adopt this attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited to the attribute configuration of the first main network node and has nothing to do with the first main network node.
  • the attribute configuration of 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. This specification does not limit this.
  • Transactions that build a blockchain subnet 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 contract called can be the aforementioned creation contract or system contract
  • the method called can be the method of establishing a blockchain subnet
  • the parameters passed in can include the above configuration information.
  • the transaction may include the following information:
  • the from field is the information of the initiator of the transaction.
  • Administrator indicates that the initiator is the administrator; the to field is the address of the called smart contract.
  • the smart contract can be a Subnet contract, then the to field is specifically the Subnet The address of the contract; the method field is the method called.
  • 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 the nodes nodeA ⁇ nodeE on Subnet0 as an example to execute a transaction that calls the AddSubnet() method in the Subnet contract. After the transaction passes the consensus, nodeA ⁇ nodeE execute the AddSubnet() method respectively and pass in the configuration information to obtain the corresponding execution results.
  • Contract execution results can be represented as events in receipts.
  • the message mechanism can realize message delivery through events in receipts to trigger blockchain nodes to perform corresponding processing.
  • the structure of the event can be, for example:
  • the number of events may be one or more; each event includes fields such as topic and data.
  • the blockchain node can listen to the topic of the event, and then perform preset processing when listening to the predefined topic, or read the relevant content from the data field of the corresponding event, and can execute the preset based on the read content. deal with.
  • the listening code can be embedded in the blockchain platform code running on the blockchain node, so that the listening 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 sends the monitored data to the predefined listening party.
  • this implementation method based on listening code is relatively more proactive compared to the event mechanism.
  • the above-mentioned 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. This manual does not limit this.
  • the execution result of the above Subnet contract may include the configuration information, and the execution result may be in the receipt mentioned above.
  • the receipt may include events related to the execution of the AddSubnet() method, that is, networking events.
  • the topic of the networking event can contain a predefined networking event identifier to distinguish it from other events.
  • 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 can determine that they have listened to the event related to the execution of the AddSubnet() method, that is, the networking event, when they listen to the topic containing the keyword subnet.
  • the events in the receipt are as follows:
  • the content of the data field may include:
  • nodeA's public key nodeA's IP, nodeA's port number...
  • nodeB s public key, nodeB’s IP, nodeB’s port number...;
  • nodeD s public key, nodeD’s IP, nodeD’s port number...;
  • 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. This information can, for example, be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the value of one or more contract states contained in the Subnet contract.
  • nodeA ⁇ nodeE can determine whether the above subnet1 already exists based on the recorded network identifiers of all created blockchain subnets; if it does not exist, it means that subnet1 is the new blockchain subnet that needs to be created currently. If it exists, it means that subnet1 already exists.
  • the above data field also contains the identity information of each node member and other contents.
  • the node device deploying the first main network node may monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member, the node device deploying the first main network node may monitor the generated receipt.
  • the node device of a main network node obtains the configuration information or genesis block contained in the networking event.
  • the first blockchain node can monitor the generated receipt, and trigger the deployment of the first blockchain node when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member.
  • the node device of a blockchain node obtains the configuration information or the genesis block included in the networking event.
  • node devices can listen directly for receipts. Assume that nodeA ⁇ nodeE are deployed on node devices 1 ⁇ 5 respectively. Node devices 1 ⁇ 5 can monitor the receipts generated by nodeA ⁇ nodeE respectively. Then when it is detected that subnet1 is a newly established blockchain subnet, 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. Taking nodeA and node device 1 as an example: If node device 1 finds that the data field contains nodeA's public key, IP address, port number and other identity information, then node device 1 obtains the configuration information from the data field based on the above message mechanism.
  • node device 1 will deploy nodeA1 locally, and then 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 based on the configuration information in the data field, nor will it generate a blockchain node in subnet1.
  • blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform relevant processing based on the monitoring results. For example, when nodeA ⁇ nodeE determines that subnet1 is a newly established blockchain subnet, they will further identify the identity information of the node members contained in the data field to determine their own processing method. For example, nodeA ⁇ nodeD will find that the data field contains their own public key, IP address, port number and other identity information. Assume that nodeA ⁇ nodeD are deployed on node devices 1 ⁇ 4 respectively.
  • nodeA will Trigger node device 1 so that node device 1 obtains configuration information from the data field based on the above message mechanism and generates a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and nodeA1 loads the generated genesis block. Thus, it becomes a subnet node in subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. Also, 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 node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1. nodes in .
  • the data field may contain identity information generated in advance for nodeA1 to nodeD1, and is different from the identity information of nodeA to nodeD.
  • node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and load the genesis block by nodeA1; or, if nodeA finds the identity information of nodeA1 in the data field, If the identity information of nodeA1 is found, then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block.
  • Other blockchain nodes or node devices are handled in a similar manner and will not be described here.
  • the execution results of the contract can include the genesis block.
  • the corresponding node devices 1 to 4 can directly obtain the genesis block from the data field through the message mechanism without having to generate it themselves, which can improve the deployment efficiency of nodeA1 to nodeD1.
  • the node device implements the deployment of a blockchain node on the node device by creating an instance running the blockchain platform code in the process.
  • the node device creates a first instance in the above process, and the first instance runs the blockchain platform code.
  • the node device creates a second instance that is different from the first instance in the above process, and the second instance runs the blockchain platform code.
  • the node device can first create a first instance in the process to form the first blockchain node in the blockchain main network; and when the node member corresponding to the node device wants to participate in forming the blockchain subnet, they can A second instance is created in the above process, which is different from the above first instance, and the second instance forms a second blockchain node in the blockchain subnet.
  • the first instance and the second instance are in the same process, since no cross-process interaction is involved, the difficulty of deploying the first subnet node can be reduced and the deployment efficiency can be improved; of course, the second instance may also be in separate nodes from the first instance.
  • the node device can create the first instance in the first process to form the first blockchain node in the blockchain main network; and when the node When the node members corresponding to the device wish to participate in building a blockchain subnet, they can start a second process that is different from the first process, and create a second instance in the second process. The second instance is different from the above-mentioned first instance. The second instance then forms a second blockchain node in the blockchain subnet.
  • each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on any node device.
  • Each blockchain node deployed on any node device The blocks generated by the nodes are stored in different storages (such as databases) on any node device, and the storage used by each blockchain node deployed on any node device is isolated from each other.
  • a blockchain subnet can be created on the blockchain mainnet.
  • subnet0 originally contains nodeA ⁇ nodeE
  • subnet1 can be formed based on subnet0.
  • This subnet1 contains 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 be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA is connected with nodeA1, nodeA2, nodeB is connected with nodeB1, nodeB2, nodeC, nodeC1 and nodeC2, nodeD and nodeD1, nodeE and nodeE2 are deployed on the same node device respectively.
  • subnet1, subnet2, etc. can be used as new blockchain mainnets, and further build blockchain subnets on this basis. The process is similar to the establishment of subnet1 or subnet2, and will not be described again here.
  • the above-mentioned method of initiating transactions on the blockchain main network to select node members to create a blockchain subnet can enable the subnet nodes of the newly created blockchain subnet to be deployed where the main network nodes of the blockchain main network are located.
  • the node device where the subnet node of the blockchain subnet is located belongs to a subset of the node device where the main network node is located.
  • the subnet node where the blockchain subnet is deployed belongs to the subset of node devices where the main network node is located.
  • the main network nodes in the blockchain main network are deployed on the node equipment.
  • blockchain subnets can also be created through other means and made subject to the management of the blockchain main network.
  • a blockchain subnet can be established on the blockchain main network through registration (hereinafter referred to as the registration networking method), and the existing blockchain network can be directly registered to the blockchain main network, so that the newly registered blockchain network can Under the management of the blockchain main network, the newly registered blockchain network becomes a blockchain subnet of the blockchain main network.
  • the subnet information of the blockchain subnet to be established is directly registered to the blockchain main network, so that the blockchain main network obtains the relevant information of the blockchain subnet to be established (by receiving and executing the area to be established) Transactions issued by the blockchain network to associate and store identity information with the subnet identifier assigned to the blockchain network to be established), such as the subnet identifier and operating status of the blockchain subnet to be established, where The public key and plug-in configuration information of each node member, the IP address and port information of each node device, etc. This information will be written into the contract status of the system contract corresponding to the blockchain main network.
  • the blockchain main network will Obtaining the management rights of the blockchain subnet to be formed and completing the registration means that the blockchain subnet is completed. Since the registration networking method does not require the designation of node members on the blockchain main network through transactions to form a blockchain subnet, the subnet nodes in the blockchain subnet established through the registration networking method can be compared with those deployed on the blockchain main network.
  • the node equipment of each node in the network is completely or partially different. For example, in Figure 1, subnet0 creates a subnet4 in the registration networking mode (not shown in Figure 1). It is assumed that the main network nodes nodeA ⁇ nodeE included in subnet0 itself are deployed separately.
  • the subnet nodes corresponding to subnet4 can be deployed on any other node devices except node devices 1 to 5, or one or more subnet nodes in subnet4 are deployed on node devices 1 to 5 respectively. Any node device within 5 (but it is still necessary to ensure that only one subnet node in subnet4 is deployed on a node device), and other subnet nodes in subnet4 are deployed on any other node device except node devices 1 to 5 , of course, the subnet nodes in subnet4 can also be deployed in node devices 1 to 5.
  • this specification proposes a method for allocating callable resources.
  • the method for allocating callable resources involved in this specification will be described in detail below with reference to FIG. 2 .
  • FIG. 2 is a flow chart of a callable resource allocation method provided by an exemplary embodiment. This method is applied to node equipment deployed with main network nodes and subnet nodes.
  • the blockchain subnet where the subnet node is located is managed by the blockchain main network where the main network node is located.
  • the node equipment Multiple callable resources are deployed.
  • the blockchain main network is deployed with a tenant rights contract.
  • the tenant rights contract maintains the corresponding relationship between each tenant and the multiple callable resources.
  • the blockchain subnet A task contract is deployed; the methods include:
  • S202 Monitor subtask events generated by the task contract, where the subtask events include the tenant identification of the first tenant and the description information of the participant node of the first subtask initiated by the first tenant.
  • the task contract is an on-chain carrier used to carry off-chain computing tasks.
  • the task contract defines several sub-tasks included in the off-chain computing tasks and is used to describe the data flow direction in an off-chain computing task. and the computing collaboration process of each node device. Since the task contract is deployed on the blockchain subnet, it is restricted that the participant nodes of the off-chain computing tasks defined by the task contract do not exceed the scope of each subnet node in the blockchain subnet. Obviously, in the same blockchain subnet, Multiple task contracts can be deployed, and the number and performance of the participating node nodes involved in different task contracts can be flexibly configured, which enables chains with different task types, task requirements, and task scales to be realized based on the same blockchain subnet.
  • the blockchain main network can also be composed of multiple blockchain subnets, and the members of the subnet nodes contained in different blockchain subnets are independent of each other, they can also be deployed in different blocks.
  • Different task contracts are deployed in the chain subnets, so that off-chain computing tasks with different needs or functions can be flexibly deployed based on blockchain subnets of different sizes or architectures. It can also be based on data isolation between different blockchain subnets. Features to adapt and satisfy management needs related to permission isolation.
  • the task contract guides the implementation of its defined off-chain computing tasks
  • Users can generate the code of the task contract through the visual contract orchestration system and deploy the task contract in the blockchain subnet, so that the task contract defines a type of workflow for off-chain computing tasks, which is embodied in several execution-dependent sequences. subtasks.
  • users who have the authority to call the task contract can create and start an off-chain computing task by initiating a task creation transaction to the task contract.
  • the task contract will be created accordingly after receiving the task creation transaction.
  • the task instance maintains the task completion status of the off-chain computing task, which is specifically reflected in the task completion status of each sub-task under the off-chain computing task.
  • the task contract responds to the task creation transaction and generates the corresponding task instance, it will further trigger the execution of the first subtask corresponding to the instance, which is reflected on the task contract as an event that generates the participant node containing the first subtask.
  • Each subnet node in the blockchain subnet can listen to this event, and the node devices of those subnet nodes that determine that they belong to the participant nodes of the first subtask will further call the node device matching the first subtask.
  • Off-chain computing resources and/or off-chain storage resources are used to execute the first sub-task off-chain.
  • the node device where the participant node is located will further initiate a request to the task contract carrying the first sub-task.
  • the result of the task execution result is returned to the transaction, so that the task contract updates the task completion status of the corresponding task instance.
  • the task contract updates the task completion status of the corresponding task instance.
  • the task completion status of the task is marked as completed, thereby triggering the execution of the next batch of subtasks according to the dependency order of each subtask included in the predefined off-chain computing task, and then generating events for the participant nodes containing the next batch of subtasks.
  • Off-chain computing tasks define and require the execution of actual tasks such as data calculation, data transfer, and data storage. These tasks that consume a large amount of resources are scheduled to be executed off-chain corresponding to each node device, thereby through the event listening mechanism and The transaction callback mechanism implements a distributed computing based on the blockchain, so that off-chain computing tasks are anchored by task contracts on the blockchain, making full use of off-chain resources while ensuring that the entire task execution process is traceable.
  • off-chain computing tasks are defined in the form of contracts and the design of off-chain computing tasks is not constrained by on-chain resources, This means that different task contracts can be designed to meet different actual needs, and on-chain collaboration can be expanded through off-chain resources.
  • the task contract maintains a task completion status corresponding to the first task; and the monitoring of subtask events generated by the task contract includes: monitoring the completion of the task corresponding to the first task of the task contract.
  • the subtask event is generated when the status satisfies the execution condition corresponding to the first subtask included in the first task.
  • the first task is the task instance of the aforementioned off-chain computing task, and its task completion status is maintained in the task contract.
  • the task contract can further determine the first subtask that needs to be executed next based on the completion status of each subtask included in the first task, thereby initiating a target for the first subtask. subtask events. Further, it also includes: when the execution of the first subtask is completed, initiating a result return transaction containing the execution result corresponding to the first subtask to the task contract through the subnet node to update the task contract maintenance The task completion status corresponding to the first task.
  • the node device executes the first subtask by calling resources and completes the execution, it will update the task completion status of the first task maintained by the task contract by initiating a result return transaction, so that the task contract can further proceed according to the The execution dependence order of each sub-task in the first task determines the next sub-task that should be executed next, and generates a sub-task event for the next sub-task.
  • the entity that monitors the subtask events generated by the task contract and initiates the result return transaction to the task contract is specifically the scheduling engine deployed on the node device.
  • the subtask event generated by the task contract monitored by the node device records the tenant identification of the first tenant and the participant node of the first subtask initiated by the first tenant.
  • the first tenant is the tenant that initiates the first subtask.
  • the first tenant initiates a task creation transaction to the task contract so that the task contract creates a task instance of the first task.
  • the first tenant In addition to recording the various tasks it contains, the first tenant The completion status of the subtask is also recorded with the first tenant as the initiator of the first task, so that every time a new subtask event needs to be generated due to the task status update of the first task, the new subtask will be The event carries the tenant ID of the first tenant to indicate the owner of the first task to be performed, so that subsequent use of different resources on the node device can be determined based on the tenant identity.
  • the subtask event includes the description information of the participant node of the first subtask, which means that the first subtask specifies the identity information of the subnet node involved, and the node device can determine the description information of the participant node by When it contains the identification information of the subnet node deployed by itself, it is judged that the subnet node it is deployed to belongs to the participant of the first subtask, so the node device needs to respond and execute the first subtask, and if the participation If the description information of the party node does not include the identification information of the subnet node deployed by itself, the node device can determine that the subnet node deployed by itself does not belong to the participant of the first subtask, so the node device will not respond to execute the first subtask. Task.
  • the task identifiers of the first task and the first subtask will also be recorded in the subtask event to distinguish different tasks and subtasks. This is mainly to facilitate subsequent node devices to complete the execution of the first subtask and return the results.
  • the first subtask also records the calculations and data transfer operations it needs to perform, and specifies the source of the required data. This information is used to inform each node device of the task type of the first subtask and its implementation method. Thereby instructing the node device to execute the first subtask as expected by the first subtask after determining the callable resource.
  • the task completion status is updated by the task contract in response to a transaction corresponding to the first task
  • the transaction corresponding to the first task is a task creation transaction corresponding to the first task initiated by the first tenant, or A result return transaction initiated by any node device after completing the execution of any sub-task included in the first task.
  • the task contract maintains task completion statuses corresponding to multiple tasks initiated by at least one tenant.
  • a task contract only defines one type of off-chain computing task, but multiple task instances corresponding to the off-chain computing task can be created, and each task instance will record the task status corresponding to the task instance. Therefore, the creation of multiple task instances maintained on the task contract can be triggered by different tenants by initiating task creation contracts to the task contract, or they can be triggered by the same tenant by initiating task creation contracts multiple times. However, These task instances all have the same execution logic, that is, the task types of each task maintained by the task contract are the same.
  • S204 When the subnet node belongs to a participant node of the first subtask, determine from the tenant rights contract the corresponding number of the first tenant in the multiple callable resources based on the tenant identification of the first tenant. the first callable resource, and calls the first callable resource to execute the first subtask.
  • the embodiment of this specification manages the callable resources of different tenants by deploying tenant permission contracts in the blockchain main network. Since each tenant may rent corresponding callable resources on each node device, any node device can When any subtask needs to be executed, the tenant permission contract needs to be used to check whether the initiator of the task to which any subtask belongs has the permission to call the callable resources on any node device.
  • the first node device determines that the subnet node deployed by itself belongs to the participant node of the first subtask, it will use the main network node deployed by the first node device to search for the first tenant in the tenant permission contract that the first tenant has permission to call.
  • Callable resources Specifically, it is necessary to find the callable resources that the first tenant has permission to call in the first node device.
  • the first tenant does not have any callable resources in the first node device that it has the authority to call, it means that the first task initiated by the first tenant does not have the relevant resource calling authority when processing the first subtask, so It will trigger the first node device to initiate a result return transaction to the task contract to indicate execution failure, thereby causing the task contract to update the completion status of the first sub-task in the first task to execution failure, and record the relevant failure reason as "Unsuccessful" Possessing permissions to relevant resources on the first node device", thereby further generating an event indicating the failure of the first task execution and the reason for the failure for monitoring by the device where the first tenant is located, or the first tenant can also query through the task contract
  • the interface directly queries the task completion status of the first task to learn that the first task has failed to execute and the corresponding failure reason.
  • the first tenant has the authority to call at least one callable resource deployed in the first node device, it will be further determined whether there is a first callable resource among these authorized callable resources that can support the execution of the first subtask.
  • resource if there is no first callable resource that can support the execution of the first subtask, it will also cause the execution of the first subtask to fail.
  • the failure reason is the same as the failure reason in the previous example, and if there is a first callable resource that can support the execution of the first subtask.
  • the first callable resource of the task indicates that the first tenant has the resource permission to execute the first subtask, and the first node device will continue to call the first callable resource to execute the first subtask.
  • the node device can call and obtain the description information of each callable resource corresponding to the first tenant maintained in the tenant rights contract by initiating a local transaction to the tenant rights contract (without the need for network-wide consensus). , you can also obtain the description information of each callable resource corresponding to the first tenant by directly reading the storage space corresponding to the tenant permission contract in the database.
  • any tenant maintained by the tenant rights contract corresponds to one or more callable resources
  • any callable resource maintained by the tenant rights contract corresponds to one or more tenants.
  • the tenant permission contract maintains all the callable resources held by any tenant on each node device. Therefore, for a tenant, it can hold multiple callable resources at the same time. At the same time, the tenant permission contract can exist at the same time. Multiple tenants hold the same callable resource at the same time, so a callable resource can be held by multiple tenants at the same time, thereby realizing resource reuse and sharing.
  • each tenant's holding information for callable resources maintained on the tenant rights contract can be updated in a variety of ways.
  • the corresponding relationship between each tenant and the multiple callable resources maintained by the tenant permission contract is updated by the tenant permission contract in response to a permission change transaction, that is, by initiating a permission change to the tenant permission contract.
  • Transactions are used to add, modify, delete, extend or shorten the validity period of the correspondence between each tenant and the multiple callable resources maintained in the tenant rights contract; for another example, on the tenant rights contract
  • Each callable resource held by the tenant maintained has a validity period. That is, the tenant permission contract maintains a timing module based on its preset validity period for each correspondence between the tenant and the callable resource. In any correspondence When the relationship exceeds the validity period, that is, when the timing module's count exceeds the corresponding validity period, the tenant permissions contract will automatically delete the corresponding relationship.
  • calling the first callable resource to execute the first subtask includes: when the first callable resource supports the resource requirements corresponding to the first subtask, calling the first callable resource to execute the first subtask.
  • the type of resource requirements includes: computing requirements, data engine requirements and/or data input requirements.
  • the types of resource requirements involved in the embodiments of this specification include computing requirements, data engine requirements, and/or data input requirements.
  • computing requirements refer to the computing operations that related subtasks need to perform, and the type of computing tasks, which is expressed as dependence on a specific type of computing engine
  • data engine requirements refer to the dependence on a specific type of data engine. Due to different types of The data access methods or types of data accessed by the data engines are different, so the different data engine requirements reflect the different requirements of the relevant subtasks for the data access methods or the types of data accessed; the data input requirements refer to the Definition of the sources of input data for relevant subtasks, e.g. expressing dependence on specific data in a specific database.
  • the types of callable resources include: computing engine, data engine and/or data source.
  • the node device is pre-deployed with multiple callable resources.
  • These callable resources are divided into computing engines, data engines and data sources according to type.
  • a computing engine refers to a service or subsystem that provides off-chain computing capabilities.
  • a computing engine can often undertake one or more types of computing tasks, which is reflected in its support for the computing requirements corresponding to related subtasks.
  • Computing engines are allocated according to tenant identities, which is equivalent to limiting the types of computing tasks that can be called by different tenants, thereby achieving permission management based on computing task types;
  • the data engine also known as the database engine, refers to the storage, retrieval, processing and
  • the core service program that protects data uses the database engine to control access permissions and process transactions quickly, thereby meeting the requirements of most applications in the enterprise that need to process large amounts of data.
  • the database engine is used to create databases for online transaction processing or online analysis and processing of data.
  • Relational databases which include the creation of tables for storing data and database objects (such as indexes, views, and stored procedures) for viewing, managing, and protecting data security, the data access methods or data types accessed by different data engines It is different, so it is reflected in the support of the data engine requirements corresponding to the relevant subtasks, and the distribution of the data engine according to the tenant identity can achieve permission control for the data access method or the data type required to be accessed; the data source refers to the node
  • the device can call a database or database server because node devices can usually maintain multiple databases (can access multiple database servers), and each database as a storage resource can be accessed by different tenants and contains different data.
  • the service types available to different tenants can be Make restrictions to achieve permission management based on service type.
  • the performance of multiple callable resources of the same type deployed on the node device can also be different. Therefore, by allocating the callable resources of the same type deployed on the node device according to the tenant identity, the same services supported by different tenants can be allocated.
  • the performance upper limit of the type is constrained to realize permission management based on the performance upper limit of the same service type.
  • the resource allocation of multiple tenants in the process of executing off-chain computing tasks using the blockchain subnet as the carrier is managed through the tenant rights contract deployed on the blockchain main network, so that multiple tenants can
  • the computing resources and/or storage resources of the node equipment where each subnet node is located are shared, so that the resources on each node equipment are fully utilized; at the same time, because different callable resources can be configured for different tenants in the tenant permission contract, Therefore, this solution for permission management of callable resources on node devices based on tenant identities can also achieve flexible allocation of callable resources on each node device.
  • the subtask event also includes: the tenant identification of the second tenant and the description information of the participant node of the second subtask initiated by the second tenant.
  • the method further includes: when the subnet node belongs to a participant node of the second subtask, determining from the tenant rights contract that the second tenant has access to the plurality of available shares based on the tenant identification of the second tenant. Call the corresponding second callable resource in the resource.
  • the method of calling the first callable resource to execute the first subtask includes: when the second callable resource is not the first callable resource, respectively calling the first callable resource and the second callable resource to execute the first callable resource in parallel. Subtask and second subtask; when the second callable resource is the first callable resource, the first callable resource is called to execute the first subtask and the second subtask serially.
  • the task contract issues multiple subtasks at the same time.
  • These subtasks usually originate from different task instances, but also Can come from the same task instance at the same time (that is, an off-chain computing task contains logic that utilizes callable resources of other tenants except the tenant that initiated the off-chain computing task), so the subtask event will also include the callable resources of each tenant.
  • the first tenant corresponds to the first subtask
  • the second tenant corresponds to the second subtask.
  • the node device will respectively find out the first callable resource and the third callable resource corresponding to the first tenant through the tenant permission contract.
  • the second callable resource corresponding to the two tenants (the first tenant and the second tenant can also be the same tenant), while trying to execute the first subtask by calling the first callable resource and calling the second subtask by calling the second callable resource.
  • Task for any callable resource deployed on the node device, it can only be called by the same subtask at the same time. Therefore, if the first callable resource and the second callable resource are different, you can call the first callable resource. While the callable resource executes the first subtask, it calls the second callable resource in parallel to execute the second subtask, thereby realizing the parallel execution of multiple subtasks.
  • first callable resource and the second callable resource are the same, then It is necessary to first call the first callable resource to perform the first subtask and then call the second callable resource to perform the second subtask in sequence, or first call the second callable resource to perform the second subtask and then call the first callable resource to perform the second subtask.
  • One subtask is to realize the serial execution of the first subtask and the second subtask.
  • it also includes: in the event that the first callable resource corresponding to the first tenant among the plurality of callable resources cannot be determined from the tenant rights contract, extract the first callable resource from the plurality of callable resources. Determine a third callable resource that supports the resource requirement corresponding to the first subtask, and call the third callable resource to execute the first subtask.
  • the node device fails to query the callable resources corresponding to the first tenant on the node device by searching for the tenant rights contract, or although it finds that the first tenant is on the node device, Holds a callable resource, but the callable resource does not support executing the first subtask.
  • the first tenant does not have the permission to execute the first subtask, so the node device does not need to respond to The subtask event executes the first subtask.
  • the first tenant in order to prioritize the mandatory execution of the subtask, the first tenant will have the permission to execute the first subtask by default, and the node device even faces the above In those cases, the first subtask will still be selected to be executed.
  • the third callable resource that supports the resource requirements corresponding to the first subtask is determined from the multiple callable resources deployed by the node device, and then directly The third callable resource is called to execute the first subtask, and after the execution of the first subtask is completed, the result return contract for the first subtask is still initiated to the task contract.
  • the current callable resources will be filtered out from the at least two callable resources based on load balancing.
  • the callable resource that is idle or called with the least frequency is used as the third resource terminal. This can achieve dynamic load balancing of callable resources and improve the resource utilization of each callable resource on the node device.
  • the method further includes: initiating a permission change transaction to the tenant permission contract through the main network node, so that the tenant permission contract maintains the corresponding relationship between the first tenant and the third callable resource. Since the above embodiment uses a third callable resource that is not held by the first tenant in the tenant rights contract to force the execution of the first subtask, in order to comply with the original intention of the enforcement (that is, by default the first tenant has the ability to execute the first subtask permissions), and also to ensure that the node device does not have to temporarily determine the callable resources again during the subsequent execution process, after the node device determines the third node device, the node device can further initiate permissions to the tenant permission contract through the main network node.
  • FIG 3 is a schematic structural diagram of a node device provided in an exemplary embodiment. As shown in Figure 3, node device 1 is simultaneously deployed with a main network node in the blockchain main network, a subnet node in the blockchain subnet, a scheduling engine and several callable resources. The callable resources of these callable resources are The calling permission information is maintained in the tenant permission contract deployed in the blockchain main network.
  • the tenant permission contract maintains "Tenant A - Node Device 1: Computing Engine A, Data Engine A, Data Source A; Node Device 2 : -- and "Tenant B - node device 1: computing engine B, data engine B, data source B; node device 2: -- means that tenant A holds on node device 1
  • the callable resources include computing engine A, data engine A and data source A
  • the callable resources held by tenant B on node device 2 include computing engine B, data engine B and data source B.
  • the scheduling engine listens through the subnet node that the description information of the task participant of the first subtask contained in the subtask event generated by the task contract contains the node identifier of node device 1, it will further read The tenant ID of the first tenant included in the subtask event. Assume that the tenant ID of the first tenant is the tenant ID of tenant A. The scheduling engine will search the tenant permission contract through the main network node to determine the rights held by tenant A on node device 1.
  • callable resources and then further determine whether these callable resources can support the resource requirements corresponding to the first subtask included in the execution subtask event (for example, relying on computing engine A and data source A), and support the first task corresponding to
  • the computing engine A and the data source A are called to execute the first subtask.
  • the execution result corresponding to the first subtask (execution success status, output result and/or the hash value of the output result or storage address) is carried in the result return transaction, and initiates the result return transaction to the task contract through the subnet node, so that the task contract updates the task completion status of the first task to which the first subtask belongs, and triggers the generation of the corresponding task for the first task.
  • Figure 4 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408 and a non-volatile memory 410.
  • the processor 402 reads the corresponding computer program from the non-volatile memory 410 into the memory 408 and then runs it.
  • the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.
  • FIG. 5 is a block diagram of a callable resource allocation device provided in this specification according to an exemplary embodiment.
  • This device can be applied to the equipment shown in Figure 4 to implement the technology of this specification.
  • Solution the device is applied to node equipment deployed with a main network node and a subnet node, and the blockchain subnet where the subnet node is located is managed by the blockchain main network where the main network node is located, so The node device is deployed with multiple callable resources, and the blockchain main network is deployed with a tenant rights contract.
  • the tenant rights contract maintains the corresponding relationship between each tenant and the multiple callable resources.
  • the zone The blockchain subnet is deployed with task contracts; the devices include:
  • the event listening unit 501 is configured to monitor subtask events generated by the task contract, where the subtask events include the tenant identification of the first tenant and the description information of the participant node of the first subtask initiated by the first tenant.
  • Resource calling unit 502 configured to determine, based on the tenant identification of the first tenant, from the tenant rights contract that the first tenant has the rights to participate in the plurality of shares when the subnet node belongs to the participant node of the first subtask.
  • the corresponding first callable resource among the callable resources is called, and the first callable resource is called to perform the first subtask.
  • the task contract maintains a task completion status corresponding to the first task.
  • the time monitoring unit 501 is specifically configured to monitor the subtask event generated by the task contract when the task completion status corresponding to the first task satisfies the execution condition corresponding to the first subtask included in the first task.
  • a task status update unit 503 configured to initiate a result return containing the execution result corresponding to the first subtask to the task contract through the subnetwork node when the first subtask is executed. Transaction to update the task completion status corresponding to the first task maintained by the task contract.
  • the task contract maintains task completion status corresponding to multiple tasks initiated by at least one tenant.
  • the resource calling unit 502 is specifically configured to: call the first callable resource to execute the first subtask when the first callable resource supports the resource requirement corresponding to the first subtask.
  • the types of resource requirements include: computing requirements, data engine requirements and/or data input requirements.
  • the types of callable resources include: computing engine, data engine and/or data source.
  • the corresponding relationship between each tenant maintained by the tenant rights contract and the multiple callable resources is updated by the tenant rights contract in response to a rights change transaction.
  • the subtask event also includes: the tenant identification of the second tenant and the description information of the participant node of the second subtask initiated by the second tenant; the device also includes: a resource confirmation unit 504, configured to When the subnet node belongs to the participant node of the second subtask, the second tenant corresponding to the plurality of callable resources is determined from the tenant permission contract based on the tenant identification of the second tenant. Callable resources.
  • the resource calling unit 502 is specifically configured to: when the second callable resource is not the first callable resource, call the first callable resource and the second callable resource to execute the first subtask and the second subtask in parallel. Task; when the second callable resource is the first callable resource, call the first callable resource to execute the first subtask and the second subtask serially.
  • a temporary resource calling unit 505 configured to call the first callable resource corresponding to the first tenant among the plurality of callable resources when the first callable resource corresponding to the first tenant cannot be determined from the tenant rights contract.
  • a third callable resource that supports the resource requirement corresponding to the first subtask is determined among the plurality of callable resources, and the third callable resource is called to execute the first subtask.
  • a permission update unit 506 configured to initiate a permission change transaction to the tenant permission contract through the main network node, so that the tenant permission contract maintains between the first tenant and the third callable resource. correspondence between.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers.
  • controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.
  • the systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions.
  • a typical implementation device is a server system.
  • the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.
  • the functions are divided into various modules and described separately.
  • the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. .
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
  • the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
  • Information may be computer-readable instructions, data structures, modules of programs, 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), and read-only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • Magnetic tape magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented 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. Product form.
  • 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 specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本说明书提供一种可调用资源的分配方法和装置,应用于部署有主网节点与子网节点的节点设备,子网节点所处的区块链子网由主网节点所处的区块链主网所管理,节点设备部署有多份可调用资源,区块链主网部署有租户权限合约,租户权限合约维护有各租户与多份可调用资源之间的对应关系,区块链子网部署有任务合约。所述方法包括:监听任务合约生成的子任务事件,子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息;在子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从租户权限合约中确定出第一租户在多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。

Description

一种可调用资源的分配方法和装置 技术领域
本说明书实施例属于区块链技术领域,尤其涉及一种可调用资源的分配方法和装置。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构,并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性,区块链也受到人们越来越多的重视和应用。在一些区块链网络中,部分节点有时存在实现小范围交易的需求,以避免其他节点获得这些交易及其相关数据。因此可以在区块链主网的基础上进一步建立区块链子网。
区块链主网上组建的区块链子网可以承担链下计算任务,此时区块链子网中的各子网节点所处节点设备会贡献计算资源或存储资源以用于实现链下计算任务,然而,节点设备上的资源常常得不到充分利用,也无法实现灵活的资源分配。
发明内容
本发明的目的在于提供一种可调用资源的分配方法和装置。
根据本说明书一个或多个实施例的第一方面,提出了一种可调用资源的分配方法,应用于部署有主网节点与子网节点的节点设备,所述子网节点所处的区块链子网由所述主网节点所处的区块链主网所管理,所述节点设备部署有多份可调用资源,所述区块链主网部署有租户权限合约,所述租户权限合约维护有各租户与所述多份可调用资源之间的对应关系,所述区块链子网部署有任务合约。所述方法包括:监听所述任务合约生成的子任务事件,所述子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息;在所述子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。
根据本说明书一个或多个实施例的第二方面,提出了一种可调用资源的分配装置,应用于部署有主网节点与子网节点的节点设备,所述子网节点所处的区块链子网由所述主网节点所处的区块链主网所管理,所述节点设备部署有多份可调用资源,所述区块链主网部署有租户权限合约,所述租户权限合约维护有各租户与所述多份可调用资源之间的对应关系,所述区块链子网部署有任务合约。所述装置包括:事件监听单元,用于监听所述任务合约生成的子任务事件,所述子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息;资源调用单元,用于在所述子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。
根据本说明书一个或多个实施例的第三方面,提出了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器。其中,所述处理器通过运行所述可执行指令以实现如第一方面所述的方法。
根据本说明书一个或多个实施例的第四方面,提出了一种计算机可读存储介质,其 上存储有计算机指令,该指令被处理器执行时实现如第一方面所述方法的步骤。
在本说明书实施例中,通过区块链主网上部署的租户权限合约来管理多个租户在执行以区块链子网为载体的链下计算任务的过程中的资源分配情况,实现多个租户能够同时共享各子网节点所处节点设备的计算资源和/或存储资源,从而使得各节点设备上的资源得到充分利用;同时,由于可以在租户权限合约中对不同租户配置不同的可调用资源,因此,这种按照租户身份对节点设备上的可调用资源进行权限管理的方案,还可以实现针对各节点设备上可调用资源的灵活分配。
附图说明
为了更清楚地说明本说明书实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是一示例性实施例提供的一种基于区块链主网组建区块链子网的示意图。
图2是一示例性实施例提供的一种可调用资源的分配方法的流程图。
图3是一示例性实施例提供的一种节点设备的结构示意图。
图4是一示例性实施例提供的一种设备的结构示意图。
图5是一示例性实施例提供的一种可调用资源的分配装置的框图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。
由于区块链网络的去中心化特性,使得区块链网络中的所有区块链节点均会维护相同的区块数据,无法满足部分节点的特殊需求。以联盟链为例,所有联盟成员(即联盟内的节点成员)可以组成一区块链网络,所有联盟成员在该区块链网络中分别存在对应的区块链节点,并可以通过对应的区块链节点获得该区块链网络上发生的所有交易和相关数据。但在一些情况下,可能存在部分联盟成员希望完成一些具有保密需求的交易,这些联盟成员既希望这些交易能够在区块链上存证或借助于区块链技术的其他优势,又能够避免其他联盟成员查看到这些交易和相关数据。虽然这些联盟成员可以额外组建一新的区块链网络,其建立方式与上述包含所有联盟成员的区块链网络类似,但是从头开始建立一条新的区块链网络需要消耗大量的资源,且无论是该区块链网络的建立过程或是建成后的配置过程都非常耗时。联盟成员之间的需求往往是临时的或者具有一定的时效性,使得新建的区块链网络很快就会由于需求消失而失去存在的意义,从而进一步增加了上述区块链网络的建链成本。而联盟成员之间的需求经常会变化,而每一需求所对应的联盟成员也往往不同,因而每当联盟成员发生变化时就可能需要组建一新的区块链网络,从而造成资源和时间的大量浪费。
为此,可以将已组建的区块链网络作为区块链主网,并在该区块链主网的基础上组建区块链子网。那么,在诸如上述的联盟链场景下,联盟成员可以在已经参与区块链主网的情况下,基于自身需求而在区块链主网的基础上组建所需的区块链子网。由于区块 链子网是在区块链主网的基础上所建立,使得区块链子网的组建过程相比于完全独立地组建一条区块链网络,所消耗的资源和所需的耗时等都极大地降低,灵活性极高。
基于区块链主网快捷组建区块链子网的过程如下:区块链主网中的各区块链节点分别获取组建区块链子网的交易,所述交易包含所述区块链子网的配置信息,所述配置信息包括参与组建所述区块链子网的节点成员的身份信息,所述区块链主网中的各区块链节点分别执行所述交易以透出所述配置信息,当所述配置信息包含第一区块链节点对应的节点成员的身份信息时,部署第一区块链节点的节点设备基于所述包含所述配置信息的创世块启动属于所述区块链子网的第二区块链节点。
以图1所示为例,区块链主网为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来发起该组建区块链子网的交易。
在区块链主网的基础上组建区块链子网时,容易理解的是,会使得该区块链子网与区块链主网之间存在逻辑上的层次关系。比如在图1所示的subnet0上组建区块链子网subnet1时,可以认为subnet0处于第一层、subnet1处于第二层。一种情况下,本说明书中的区块链主网可以为底层区块链网络,即区块链主网并非在其他区块链网络的基础上组建的区块链子网,比如图1中的subnet0可以认为属于底层区块链网络类型的区块链主网。另一种情况下,本说明书中的区块链主网也可以为其他区块链网络的子网,比如可以在图1中subnet1的基础上进一步组建另一区块链子网,此时可以认为subnet1为该区块链子网对应的区块链主网,而这并不影响该subnet1同时属于subnet0上创建的区块链子网。可见,区块链主网与区块链子网实际上是相对概念,同一区块链网络在一些情况下可以为区块链主网、另一些情况下可以为区块链子网。
上述组建区块链子网的交易在被发送至区块链主网后,由区块链主网内的共识节点进行共识,并在通过共识后由各主网节点执行该交易,以完成区块链子网的组建。共识过程取决于所采用的共识机制,本说明书并不对此进行限制。
通过在上述组建区块链子网的交易中包含配置信息,该配置信息可以用于对所组建的区块链子网进行配置,使得组建的区块链子网符合组网需求。例如,通过在配置信息中包含节点成员的身份信息,可以指定组建的区块链子网包含哪些区块链节点。
节点成员的身份信息可以包括节点的公钥,或者采用节点ID等其他能够表征节点身份的信息,本说明书并不对此进行限制。以公钥为例,每个区块链节点都存在对应的一组或多组公私钥对,由区块链节点持有私钥而公钥被公开且唯一对应于该私钥,因而可以通过公钥来表征相应区块链节点的身份。因此,对于希望作为区块链子网的节点成员的区块链节点,可以将这些区块链节点的公钥添加至上述组建区块链子网的交易中,以作为上述节点成员的身份信息。上述的公私钥对可以用于签名验证的过程。例如,在采用有签名的共识算法中,譬如subnet1上述的nodeA1采用自身维护的私钥对消息进行签名后,将经过签名的消息在subnet1中广播,而nodeB1、nodeC1和nodeD1可以用nodeA1的公钥对收到的消息进行签名验证,以确认自身收到的消息确实来自nodeA1且 没有经过篡改。
第一主网节点可以为区块链主网上属于配置信息所指示的节点成员的区块链节点。在组建区块链子网时,并非由第一主网节点直接参与组建区块链子网、成为其节点成员,而是需要由用于部署该第一主网节点的节点设备生成第一子网节点,并由第一子网节点成为区块链子网中的节点成员。第一主网节点和第一子网节点对应于同一个区块链成员,比如在联盟链场景下对应于同一联盟链成员,但第一主网节点属于区块链主网、第一子网节点属于区块链子网,使得该区块链成员可以分别参与到区块链主网和区块链子网的交易中;并且,由于区块链主网和区块链子网属于相互独立的两个区块链网络,使得第一主网节点生成的区块与第一子网节点生成的区块分别存入所述节点设备上的不同存储(采用的存储譬如可以为数据库),实现了第一主网节点与第一子网节点分别使用的存储之间的相互隔离,因而区块链子网所产生的数据仅会在区块链子网的节点成员之间同步,使得仅参与了区块链主网的区块链成员无法获得区块链子网上产生的数据,实现了区块链主网与区块链子网之间的数据隔离,满足了部分区块链成员(即参与区块链子网的区块链成员)之间的交易需求。
可见,第一主网节点和第一子网节点是在逻辑上划分出来的区块链节点,而从物理设备的角度来说,相当于上述部署了第一主网节点和第一子网节点的节点设备同时参与了区块链主网和区块链子网。由于区块链主网与区块链子网之间相互独立,使得这两个区块链网络的身份体系也相互独立,因而即便第一主网节点和第一子网节点可以采用完全相同的公钥,仍然应当将两者视为不同的区块链节点。譬如在图1中,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()方法并传入配置信息,得到相应的执行结果。
区块链网络中的节点在执行调用智能合约的交易后,会生成相应的收据(receipt),以用于记录与执行该智能合约相关的信息。这样,可以通过查询交易的收据来获得合约执行结果的相关信息。合约执行结果可以表现为收据中的事件(event)。消息机制可以通过收据中的事件实现消息传递,以触发区块链节点执行相应的处理。事件的结构譬如可以为:
Event:
[topic][data]
[topic][data]
......
在上述示例中,事件的数量可以为一个或多个;其中,每个事件分别包括主题(topic)和数据(data)等字段。区块链节点可以通过监听事件的topic,从而在监听到预定义的topic的情况下,执行预设处理,或者从相应事件的data字段读取相关内容,以及可以基于读取的内容执行预设处理。
上述的事件机制中,相当于在监听方(比如存在监听需求的用户)处存在具有监听功能的客户端,譬如该客户端上运行了用于实现监听功能的SDK等,由该客户端对区块链节点产生的事件进行监听,而区块链节点只需要正常生成收据即可。除了上述的事件机制之外,还可以通过其他方式实现交易信息的透出。例如,可以通过在区块链节点运行的区块链平台代码中嵌入监听代码,使得该监听代码可以监听区块链交易的交易内容、智能合约的合约状态、合约产生的收据等其中的一种或多种数据,并将监听到的数据发送至预定义的监听方。由于监听代码部署于区块链平台代码中,而非监听方的客户端处,因而相比于事件机制而言,这种基于监听代码的实现方式相对更加的主动。其中,上述的监听代码可以由区块链平台的开发人员在开发过程中加入区块链平台代码,也可以由监听方基于自身的需求而嵌入,本说明书并不对此进行限制。
可见,上述Subnet合约的执行结果可以包括所述配置信息,该执行结果可以处于前文所述的收据中,该收据中可以包含与执行AddSubnet()方法相关的event,即组网事件。组网事件的topic可以包含预定义的组网事件标识,以区别于其他的事件。譬如在与执行AddSubnet()方法相关的event中,topic的内容为关键词subnet,且该关键词区别于其 他方法所产生event中的topic。那么,nodeA~nodeE通过监听生成的收据中各个event所含的topic,可以在监听到包含关键词subnet的topic的情况下,确定监听到与执行AddSubnet()方法相关的event,即组网事件。例如,收据中的event如下:
Event:
[topic:other][data]
[topic:subnet][data]
......
那么,nodeA~nodeE在监听到第1条event时,由于所含topic的内容为other,确定该event与AddSubnet()方法无关;以及,nodeA~nodeE在监听到第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合约所含的一个或多个合约状态的取值。那么,nodeA~nodeE可以根据记录的已创建的所有区块链子网的网络标识,确定上述的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中的1个子网节点;类似地,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的部署效率。
节点设备通过在该进程中创建一个运行区块链平台代码的实例,实现在该节点设备上部署一区块链节点。对于第一主网节点而言,由节点设备在上述进程中创建第一实例,并由该第一实例运行区块链平台代码而形成。类似地,对于第一子网节点而言,由节点设备在上述进程中创建区别于第一实例的第二实例,并由该第二实例运行区块链平台代码而形成。例如,节点设备可以首先在进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可以在上述进程中创建第二实例,该第二实例区别于上述的第一实例,并由该第二实例形成区块链子网中的第二区块链节点。当第一实例与第二实例位于同一进程时,由于不涉及跨进程交互,可以降低对第一子网节点的部署难度、提高部署效率;当然,第二实例也可能与第一实例分别处于节点设备上的不同进程中,本说明书并不对此进行限制;例如,节点设备可以在第一进程中创建第一实例,以形成区块链主网中的第一区块链节点;而当该节点设备对应的节点成员希望参与组建区块链子网时,可以启动区别于第一进程的第二进程,并在该第二进程中创建第二实例,该第二实例区别于上述的第一实例,进而由该第二实例形成区块链子网中的第二区块链节点。事实上,本说明书实施例中涉及的任一节点设备上部署的各区块链节点均为运行在所述任一节点设备上的不同的区块链实 例,任一节点设备上部署的各区块链节点生成的区块分别存入所述任一节点设备上的不同存储(例如数据库),且任一节点设备部署的各区块链节点分别使用的存储之间相互隔离。
通过上述方式,可以在区块链主网上创建出区块链子网。以图1为例,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的组建相似,此处不再赘述。可见,上述在区块链主网上发起交易选取节点成员以创建区块链子网的方式,可以使得新创建的区块链子网的子网节点均部署在区块链主网的主网节点所在的节点设备上,也就是从节点设备的角度上来说,区块链子网的子网节点所在的节点设备属于主网节点所在节点设备的子集,换言之,部署有区块链子网的子网节点所处的节点设备上部署有区块链主网中的主网节点。
除了通过上述在区块链主网上发起交易选取节点成员以创建区块链子网的方式,还可以通过其他手段创建区块链子网,并使得其受到区块链主网的管理。例如,可以通过注册方式在区块链主网上组建区块链子网(后续简称注册组网方式),将现有区块链网络直接注册至区块链主网,使新注册的区块链网络受到区块链主网的管理,从而使得新注册的区块链网络成为区块链主网的区块链子网。通过注册组网方式,待组建区块链子网的子网信息被直接注册至区块链主网,使得区块链主网获取待组建区块链子网的相关信息(通过接收并执行待组建区块链网络发出的、用于将其身份信息与分配至该待组建区块链网络的子网标识进行关联存证的交易),例如待组建区块链子网的子网标识和运行状态,其中各节点成员的公钥和插件配置信息、各节点设备的IP地址和端口信息等,这些信息会被写入区块链主网对应的系统合约的合约状态中,由此区块链主网将获取该待组建区块链子网的管理权,在完成注册后,便意味着区块链子网组建完成。由于注册组网方式并不需要通过交易在区块链主网上指定节点成员构成区块链子网,因此通过注册组网方式组建的区块链子网中的子网节点可以与部署在区块链主网中各节点的节点设备完全不同或部分不同,例如图1中subnet0以注册组网方式创建了一个subnet4(图1中未示出),假设subnet0自身所包含的主网节点nodeA~nodeE分别部署于节点设备1~5,那么subnet4对应的子网节点可以部署于除节点设备1~5外的其他任意节点设备上,或者,subnet4中的其中一个或多个子网节点分别部署于节点设备1~5内的任意节点设备(但仍需要保证一个节点设备上仅部署subnet4中的一个子网节点),而subnet4中的其他的子网节点部署于除节点设备1~5外的其他任意节点设备上,当然,subnet4中的子网节点也可以均部署于节点设备1~5之中。
在区块链主网上组建的区块链子网承担链下计算任务的场景下,区块链子网中的各子网节点所处的节点设备各自均会贡献自身的计算资源或存储资源以用于实现链下计算任务,然而,节点设备上的资源常常得不到充分利用,也无法实现灵活的资源分配。有鉴于此,本说明书提出了一种可调用资源的分配方法,下面结合图2对本说明书涉及的可调用资源的分配方法进行详细说明。
图2是一示例性实施例提供的一种可调用资源的分配方法的流程图。该方法应用于部署有主网节点与子网节点的节点设备,所述子网节点所处的区块链子网由所述主网节点所处的区块链主网所管理,所述节点设备部署有多份可调用资源,所述区块链主网部署有租户权限合约,所述租户权限合约维护有各租户与所述多份可调用资源之间的对应 关系,所述区块链子网部署有任务合约;所述方法包括:
S202:监听所述任务合约生成的子任务事件,所述子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息。
在本说明书实施例中,任务合约是一个用于承载链下计算任务的链上载体,任务合约中定义有链下计算任务包含的若干子任务,用于描述一个链下计算任务中的数据流向和各节点设备的计算协作过程。由于任务合约部署在区块链子网上,因此限定了任务合约所定义的链下计算任务的参与方节点不超过区块链子网中的各子网节点的范围,显然,同一个区块链子网中可以部署多个任务合约,而不同的任务合约其所涉及的参与方节点的数量和性能均可以灵活配置,这使得依托于同一个区块链子网实现不同任务类型、任务需求和任务规模的链下计算任务的部署;另外,由于区块链主网也可以组件多个区块链子网,而不同的区块链子网所包含的子网节点的成员彼此独立,因此也可以在不同的区块链子网中分别部署不同的任务合约,从而依托于不同规模或架构的区块链子网来灵活部署具有不同需求或功能的链下计算任务,同时也能基于不同区块链子网之间数据隔离的特性来适应与满足与权限隔离相关的管理需求。
为了说明任务合约如何指导以实现其定义的链下计算任务,下面将通过一个典型的任务合约的运作过程来简单介绍链下计算任务的实现逻辑。用户可以通过可视化合约编排系统生成任务合约的代码并在区块链子网中部署任务合约,从而使得任务合约定义了一种类型的链下计算任务的工作流程,它体现为若干个具有执行依赖顺序的子任务。在任务合约部署成功后,有权限调用该任务合约的用户就可以通过向任务合约发起任务创建交易的方式来创建并启动一个链下计算任务,任务合约在接收到任务创建交易后会相应地创建一个归属于发起方用户的链下计算任务的任务实例,该任务实例中维护有链下计算任务的任务完成状态,具体体现为链下计算任务下各子任务的任务完成状态。任务合约响应于任务创建交易并生成对应的任务实例后,会进一步触发执行该实例对应的第一个子任务,在任务合约上体现为生成包含第一个子任务的参与方节点的事件,区块链子网中的各子网节点都可以监听该事件,并且那些判定自身属于第一个子任务的参与方节点的子网节点所处的节点设备会进一步调用匹配于该第一个子任务的链下计算资源和/或链下存储资源来在链下执行该第一个子任务,最后,参与方节点所处的节点设备在执行完毕后,会进一步向任务合约发起携带有第一个子任务的执行结果的结果返回交易,从而使得任务合约更新对应任务实例的任务完成状态,例如当第一个子任务的执行结果为执行成功时,任务合约就会将对应任务实例中第一个子任务的任务完成状态标记为已完成,从而按照预定义的链下计算任务包含的各子任务的依赖顺序触发执行下一批子任务,进而生成包含下一批子任务的参与方节点的事件以供区块链子网中的各子网节点监听,其后续过程与前述处理第一个子任务的过程类似。由此一来,就形成了一个“任务合约更新任务完成状态→任务合约生成子任务事件→子网节点监听子任务事件并由被指定的节点设备执行子任务→节点设备向任务合约发起子任务的结果返回交易→任务合约更新任务完成状态”的循环,直至任务合约中任务实例中所有子任务的任务完成状态均为已完成的情况下,确定该任务实例对应的链下计算任务已经执行完成。
不难发现,任务合约在链下计算任务的执行过程中所执行的任务仅包括创建任务实例、接收子任务结果、子任务调度与子任务下发这类调度性任务,实际上并没有真正执行链下计算任务所定义和要求执行的如数据计算、数据转移和数据存储等实际任务,而这些大量消耗资源的任务被调度至各节点设备所对应的链下进行执行,从而通过事件监听机制以及交易回传机制实现了一种基于区块链的分布式计算,使链下计算任务被区块链上的任务合约所锚定,在确保任务执行全流程可追踪的前提下充分利用链下资源,同时使得不同节点设备之间依托于区块链实现可信的信息交互与协作计算,另外由于链下计算任务是以合约形式定义且链下计算任务的设计并不受到链上资源的掣肘,这意味着 可通过设计不同的任务合约以满足不同的实际需求,通过链下资源扩展了链上协作方式。
在本说明书实施例中,所述任务合约维护有第一任务对应的任务完成状态;所述监听所述任务合约生成的子任务事件,包括:监听所述任务合约在第一任务对应的任务完成状态满足第一任务包含的第一子任务对应的执行条件的情况下生成的所述子任务事件。在本说明书实施例中,第一任务即为前述的链下计算任务的任务实例,其任务完成状态维护在任务合约中,由于第一任务包含的各子任务的执行依赖顺序已经预先定义,这意味着每个子任务的执行条件也已确定,因此任务合约可以依据第一任务中包含的各子任务的完成状态来进一步确定接下来所需执行的第一子任务,从而发起针对第一子任务的子任务事件。进一步的,还包括:在第一子任务执行完毕的情况下,通过所述子网节点向所述任务合约发起包含第一子任务对应的执行结果的结果返回交易,以更新所述任务合约维护的第一任务对应的任务完成状态。如前所述,在节点设备通过调用资源执行第一子任务并执行完毕的情况下,会通过发起结果返回交易来更新任务合约维护的第一任务的任务完成状态,从而使得任务合约可以进一步根据第一任务中各子任务的执行依赖顺序确定接下来所应该执行的下一子任务,并生成针对下一子任务的子任务事件。在本说明书实施例中,监听任务合约生成的子任务事件、向任务合约发起结果返回交易的实体具体为所述节点设备上部署的调度引擎。
在本说明书实施例中,节点设备监听到的所述任务合约生成的子任务事件中记录有第一租户的租户标识以及第一租户发起的第一子任务的参与方节点。其中,第一租户即发起第一子任务的租户,例如第一租户是通过向任务合约发起任务创建交易从而使任务合约创建了第一任务的任务实例,该任务实例除了记录有其包含的各子任务的完成状态,还记录有作为第一任务的发起者的第一租户,这样在每次因为第一任务的任务状态更新而需要生成新的子任务事件时,就会在新的子任务事件中携带第一租户的租户标识,以表明所需执行的第一任务的所属方,方便后续根据租户身份来确定使用节点设备上不同的资源。同时,子任务事件包括第一子任务的参与方节点的描述信息,是指第一子任务规定了其涉及的子网节点的身份信息,节点设备可以通过在确定所述参与方节点的描述信息中包含自身部署的子网节点的标识信息的情况下,判断自身所部属的子网节点属于第一子任务的参与方,于是节点设备就需要响应并执行第一子任务,而如果所述参与方节点的描述信息中不包含自身部署的子网节点的标识信息,则节点设备可以判断自身所部署的子网节点不属于第一子任务的参与方,于是节点设备将不响应执行第一子任务。另外,子任务事件中还会记录第一任务与第一子任务的任务标识,从而对不同的任务和子任务进行区分,这主要是方便后续节点设备在对第一子任务执行完毕并回传结果返回交易时能够正确标识是针对第一任务中第一子任务的结果,使得任务合约能够通过结果返回交易正确更新第一任务中第一子任务的完成状态,以应对同一个任务包含多个子任务以及同一个租户同时创建多个任务的情况。当然第一子任务还记录有自身所需执行的计算和数据转移等操作,且指定了所需数据的来源,这些信息是用于告知各节点设备第一子任务的任务类型及其实现方式,从而指导节点设备在确定可调用资源后按照第一子任务的预期执行第一子任务。
如前所述,所述任务完成状态由所述任务合约响应于第一任务对应的交易触发更新,所述第一任务对应的交易为第一租户发起的第一任务对应的任务创建交易,或者任一节点设备在对第一任务包含的任一子任务执行完毕的情况下发起的结果返回交易。
在本说明书实施例中,所述任务合约维护有至少一个租户各自发起的多个任务分别对应的任务完成状态。通常情况下,一个任务合约只会定义一种类型的链下计算任务,但可以创建该链下计算任务对应的多个任务实例,每个任务实例都会记录有该任务实例对应的任务状态。因此,任务合约上维护的多个任务实例可以是不同的租户通过向任务合约分别发起任务创建合约而触发创建的,也可以是由同一个租户通过多次发起任务创 建合约而触发创建的,但这些任务实例都具有相同的执行逻辑,即任务合约维护的各任务的任务类型相同。
S204:在所述子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。
本说明书实施例通过部署在区块链主网中租户权限合约来对不同租户的可调用资源进行管理,由于每个租户可能在各节点设备都租用有对应的可调用资源,因此在任一节点设备需要执行任一子任务时,都需要通过租户权限合约来检查该任一子任务所属任务的发起方是否具有调用该任一节点设备上可调用资源的权限。
例如,第一节点设备在判断自身部署的子网节点属于第一子任务的参与方节点的情况下,将通过第一节点设备部署的主网节点查找租户权限合约中第一租户有权限调用的可调用资源,具体而言,需要查找第一租户在第一节点设备中有权限调用的可调用资源。如果查找出第一租户在第一节点设备中没有任何有权限调用的可调用资源,则说明第一租户发起的该第一任务在处理第一子任务时暂不具备相关的资源调用权限,于是会触发第一节点设备向任务合约发起用于表明执行失败的结果返回交易,从而使得任务合约将第一任务中的第一子任务的完成状态更新为执行失败,同时记录相关失败原因为“未拥有第一节点设备上相关资源的权限”,从而进一步生成用于表明第一任务执行失败以及失败原因的事件以供第一租户所处设备进行监听,或者第一租户也可以通过任务合约的查询接口直接查询第一任务的任务完成情况从而获知第一任务已经执行失败以及相应的失败原因。而如果查找出第一租户有权限调用第一节点设备中部署的至少一份可调用资源,则会进一步判断这些有权限的可调用资源中是否存在能够支持执行第一子任务的第一可调用资源,如果不存在可支持执行第一子任务的第一可调用资源,则同样会导致第一子任务执行失败,失败原因与前述例子中的失败原因相同,而如果存在可支持执行第一子任务的第一可调用资源,则说明第一租户具备执行第一子任务的资源权限,进而第一节点设备将继续调用第一可调用资源执行第一子任务。
在本说明书实时例中,节点设备可以通过向租户权限合约发起本地交易(无需进行全网共识)的形式来调用并获取租户权限合约中维护的第一租户所对应的各可调用资源的描述信息,也可以通过直接读取数据库中租户权限合约对应的存储空间来获取第一租户所对应的各可调用资源的描述信息。
在本说明书实施例中,所述租户权限合约维护的任一租户对应于一份或多份可调用资源,所述租户权限合约维护的任一可调用资源对应于一个或多个租户。租户权限合约上维护有任一租户在各节点设备上所持有的所有可调用资源,因此对于一个租户而言,其可以同时持有多个可调用资源,同时,租户权限合约上可以同时存在多个租户同时持有同一个可调用资源,因此对于一个可调用资源而言,其同时可以被多个租户所持有,从而实现资源复用与共享。
在本说明书实施例中,租户权限合约上维护的各租户针对可调用资源的持有信息可以通过多种方式实现更新。例如,所述租户权限合约维护的所述各租户与所述多份可调用资源之间的对应关系由所述租户权限合约响应于权限变更交易触发更新,即可以通过向租户权限合约发起权限变更交易的方式,来对租户权限合约中维护的所述各租户与所述多份可调用资源之间的对应关系进行增加、修改、删除、延长或缩短有效期等操作;又例如,租户权限合约上维护的每个租户所持有的可调用资源均存在一个有效期,即租户权限合约针对每条租户与可调用资源的对应关系都对应维护有一个基于其预设有效期的计时模块,而在任一条对应关系超出有效期即计时模块的计时数超过对应有效期的情况下,租户权限合约将自动删除该条对应关系。
在本说明书实施例中,所述调用第一可调用资源执行第一子任务,包括:在第一可调用资源支持第一子任务对应的资源需求的情况下,调用第一可调用资源执行第一子任务,所述资源需求的类型包括:计算需求、数据引擎需求和/或数据输入需求。如前所述,节点设备在通过租户权限合约查找到第一租户在所述节点设备上所能够调用的第一可调用资源的情况下,还会进一步判断第一可调用资源是否支持执行第一子任务,也即第一可调用资源是否支持第一子任务对应的资源需求,从而在第一可调用资源支持第一子任务对应的资源需求的情况下调用第一可调用资源执行第一子任务。本说明书实施例所涉及的资源需求的类型包括计算需求、数据引擎需求和/或数据输入需求。其中,计算需求是指相关子任务需要进行怎样的计算操作,其计算任务的类型如何,表达为对特定类型计算引擎的依赖;数据引擎需求是指对特定类型的数据引擎的依赖,由于不同类型的数据引擎所支持的数据访问方式或访问的数据类型有所不同,因此不同的数据引擎需求反映了相关子任务对数据访问方式或访问数据的类型的要求有所不同;数据输入需求是指对相关子任务的输入数据的来源的定义,例如表达对特定数据库中特定数据的依赖。
在本说明书实施例中,所述可调用资源的类型包括:计算引擎、数据引擎和/或数据源。节点设备预先部署有多份可调用资源,这些可调用资源按照类型分为计算引擎、数据引擎和数据源。其中,计算引擎是指提供链下计算能能力的服务或子系统,一个计算引擎往往能够承担一种或多种类型的计算任务,这体现在对相关子任务对应的计算需求的支持,而对计算引擎按照租户身份进行分配,相当于对不同租户可调用的计算任务的类型进行限制,从而实现基于计算任务类型的权限管理;数据引擎又称数据库引擎,是指用于存储、检索、处理和保护数据的核心服务程序,利用数据库引擎可控制访问权限并快速处理事务,从而满足企业内大多数需要处理大量数据的应用程序的要求,使用数据库引擎创建用于联机事务处理或联机分析处理数据的关系数据库,这包括创建用于存储数据的表和用于查看、管理和保护数据安全的数据库对象(如索引、视图和存储过程),不同的数据引擎所支持的数据访问方式或访问的数据类型有所不同,因此体现为相关子任务对应的数据引擎需求的支持,而对数据引擎按照租户身份进行分配,可以实现针对数据访问方式或所需访问的数据类型的权限控制;数据源是指节点设备所能够调用数据库或数据库服务器,由于节点设备通常可以维护多个数据库(可访问多个数据库服务器),而各个数据库作为一种存储资源可以由不同的租户进行访问,其所包含的数据各不相同,因此体现为对相关子任务对应的输入数据需求的支持,而对数据源按照租户身份进行分配,则相当于对相关子任务在执行过程中对所能访问的数据范围的限制,即实现特定数据库的读取/写入权限的权限管理。由此可见,如果将计算引擎所支持的计算任务类型、数据引擎所支持的数据访问方式或所需访问的数据类型以及可支持访问的数据源均视为服务类型的不同表达形式,那么由于所述节点设备上部署的所述多份可调用资源所支持的服务类型不完全相同,因此按照租户身份对节点设备上部署的多份可调用资源进行分配,可以对不同租户所能获得的服务类型进行限制,从而实现基于服务类型的权限管理。当然,节点设备部署的同种类型的多份可调用资源的性能也可以不同,因此按照租户身份对节点设备上部署的同种类型的可调用资源进行分配,可以对不同租户所支持的相同服务类型的性能上限进行约束,从而实现基于同种服务类型的性能上限的权限管理。
在本说明书实施例中,通过区块链主网上部署的租户权限合约来管理多个租户在执行以区块链子网为载体的链下计算任务的过程中的资源分配情况,实现多个租户能够同时共享各子网节点所处节点设备的计算资源和/或存储资源,从而使得各节点设备上的资源得到充分利用;同时,由于可以在租户权限合约中对不同租户配置不同的可调用资源,因此,这种按照租户身份对节点设备上的可调用资源进行权限管理的方案,还可以实现针对各节点设备上可调用资源的灵活分配。
可选的,所述子任务事件还包括:第二租户的租户标识与第二租户发起的第二子任 务的参与方节点的描述信息。所述方法还包括:在所述子网节点属于第二子任务的参与方节点的情况下,基于第二租户的租户标识从所述租户权限合约中确定出第二租户在所述多份可调用资源中对应的第二可调用资源。所述调用第一可调用资源执行第一子任务,包括:在第二可调用资源不为第一可调用资源的情况下,分别调用第一可调用资源与第二可调用资源并行执行第一子任务与第二子任务;在第二可调用资源为第一可调用资源的情况下,调用第一可调用资源串行执行第一子任务与第二子任务。
在本说明书实施例中,在子任务事件同时包含多个租户的租户标识情况下,这意味着任务合约同时下发了多个子任务,这些子任务通常都分别来源于不同的任务实例,但也可以同时来自于同一个任务实例(即一个链下计算任务包含利用除发起该链下计算任务的租户以外的其他租户的可调用资源的逻辑),于是子任务事件中也会包含每个租户所对应的子任务,例如第一租户对应于第一子任务,第二租户对应于第二子任务,此时节点设备会通过租户权限合约分别查找出第一租户对应的第一可调用资源与第二租户对应的第二可调用资源(第一租户与第二租户也可以是同一租户),同时试图通过调用第一可调用资源执行第一子任务而通过调用第二可调用资源调用第二子任务。然而,对于节点设备上部署的任一可调用资源而言,其同一时间仅能被同一个子任务所调用,因此对于第一可调用资源与第二可调用资源不同的情况,可以在调用第一可调用资源执行第一子任务的同时并行调用第二可调用资源执行第二子任务,从而实现多个子任务的并行执行,而对于第一可调用资源与第二可调用资源相同的情况,则需要按照顺序先调用第一可调用资源执行第一子任务后调用第二可调用资源执行第二子任务,或者先调用第二可调用资源执行第二子任务后调用第一可调用资源执行第一子任务,即实现第一子任务与第二子任务的串行执行。通过本说明书实施例,可以根据多个租户资源分配情况实现多个子任务的并行执行或串行执行,从而提高各节点设备在单位时间内的资源利用率,提高系统中一个或多个链下计算任务的任务执行效率。
可选的,还包括:在无法从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源的情况下,从所述多份可调用资源中确定出支持第一子任务对应的资源需求的第三可调用资源,并调用第三可调用资源执行第一子任务。在前文所述的实施例中,如果节点设备通过查找租户权限合约,未能查询得到第一租户在所述节点设备所对应的可调用资源,或者虽然查找到第一租户在所述节点设备上持有可调用资源,但该可调用资源并不支持执行第一子任务,在上述这些情况下通常是认为第一租户不具备执行第一子任务的权限,因此所述节点设备不需要响应于子任务事件执行第一子任务,然而,在本说明实施例中,为了优先确保子任务执行的强制性,则会默认第一租户具有执行第一子任务的权限,而节点设备即使面临上述的那些情况中会依然选择执行第一子任务,具体而言,是从所述节点设备部署的多份可调用资源中确定出支持第一子任务对应的资源需求的第三可调用资源,然后直接调用第三可调用资源执行第一子任务,并在第一子任务执行完毕后依然向任务合约发起针对第一子任务的结果返回合约。需要指出的是,如果所述多份可调用资源中存在至少两份可调用资源均支持第一子任务对应的资源需求,则会根据负载均衡从所述至少两份可调用资源中筛选出当前处于空闲状态或被调用频率最少的可调用资源作为第三资源终端,如此可以实现可调用资源的动态负载均衡,提高节点设备上各可调用资源的资源利用率。
进一步的,还包括:通过所述主网节点向所述租户权限合约发起权限变更交易,以使所述租户权限合约维护有第一租户与第三可调用资源之间的对应关系。由于上述实施例使用了租户权限合约中第一租户所未持有的第三可调用资源强制执行了第一子任务,因此为了符合强制执行的本意(即默认第一租户具有执行第一子任务的权限),也为了确保后续执行过程中不必由节点设备再次临时确定可调用资源,可以在节点设备确定出第三节点设备之后,由节点设备进一步通过主网节点向所述租户权限合约发起权限变更 交易,使租户权限合约维护有新增的第一租户与第三可调用资源之间的对应关系,即视为第一租户已持有第三可调用资源的调用权限,以后再次执行第一租户对应的子任务时就可以通过租户权限合约直接确定出第一租户具有第三可调用资源的调用权限。
图3是一示例性实施例提供的一种节点设备的结构示意图。如图3所示,节点设备1中同时部署有区块链主网中的一个主网节点、区块链子网中的一个子网节点、调度引擎与若干可调用资源,这些可调用资源的可调用权限信息被维护在区块链主网中部署的租户权限合约中,例如租户权限合约中维护有“租户A——节点设备1:计算引擎A、数据引擎A、数据源A;节点设备2:……”与“租户B——节点设备1:计算引擎B、数据引擎B、数据源B;节点设备2:……”的对应关系,则意味着租户A在节点设备1所持有的可调用资源包括计算引擎A、数据引擎A与数据源A,而租户B在节点设备2所持有的可调用资源包括计算引擎B、数据引擎B与数据源B。于是,当调度引擎通过子网节点监听到任务合约所生成的子任务事件中包含的第一子任务的任务参与方的描述信息中包含节点设备1的节点标识的情况下,就会进一步读取子任务事件中包含的第一租户的租户标识,假设第一租户的租户标识为租户A的租户标识,调度引擎将通过主网节点查找租户权限合约以确定租户A在节点设备1上持有的可调用资源,然后进一步判断这些可调用资源能否支持执行子任务事件中包含的第一子任务对应的资源需求(例如表现为依赖计算引擎A与数据源A),并在支持第一任务对应的资源需求的情况下调用计算引擎A与数据源A执行第一子任务,执行完毕后将第一子任务对应的执行结果(执行成功情况、输出结果和/或输出结果的哈希值或存储地址)携带在结果返回交易中,并通过子网节点向任务合约发起结果返回交易,从而使得任务合约更新第一子任务所属的第一任务的任务完成状态,并触发生成针对第一任务对应的下一轮的子任务的子任务事件或声明第一任务执行完毕。
图4是一示例性实施例提供的一种设备的示意结构图。请参考图4,在硬件层面,该设备包括处理器402、内部总线404、网络接口406、内存408以及非易失性存储器410,当然还可能包括其他功能所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现,比如由处理器402从非易失性存储器410中读取对应的计算机程序到内存408中然后运行。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
如图5所示,图5是本说明书根据一示例性实施例提供的一种可调用资源的分配装置的框图,该装置可以应用于如图4所示的设备中,以实现本说明书的技术方案;所述装置应用于部署有主网节点与子网节点的节点设备,所述子网节点所处的区块链子网由所述主网节点所处的区块链主网所管理,所述节点设备部署有多份可调用资源,所述区块链主网部署有租户权限合约,所述租户权限合约维护有各租户与所述多份可调用资源之间的对应关系,所述区块链子网部署有任务合约;所述装置包括:
事件监听单元501,用于监听所述任务合约生成的子任务事件,所述子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息。
资源调用单元502,用于在所述子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。
可选的,所述任务合约维护有第一任务对应的任务完成状态。所述时间监听单元501具体用于:监听所述任务合约在第一任务对应的任务完成状态满足第一任务包含的第一子任务对应的执行条件的情况下生成的所述子任务事件。
可选的,还包括:任务状态更新单元503,用于在第一子任务执行完毕的情况下, 通过所述子网节点向所述任务合约发起包含第一子任务对应的执行结果的结果返回交易,以更新所述任务合约维护的第一任务对应的任务完成状态。
可选的,所述任务合约维护有至少一个租户各自发起的多个任务分别对应的任务完成状态。
可选的,所述资源调用单元502具体用于:在第一可调用资源支持第一子任务对应的资源需求的情况下,调用第一可调用资源执行第一子任务。所述资源需求的类型包括:计算需求、数据引擎需求和/或数据输入需求。
可选的,所述可调用资源的类型包括:计算引擎、数据引擎和/或数据源。
可选的,所述租户权限合约维护的所述各租户与所述多份可调用资源之间的对应关系由所述租户权限合约响应于权限变更交易触发更新。
可选的,所述子任务事件还包括:第二租户的租户标识与第二租户发起的第二子任务的参与方节点的描述信息;所述装置还包括:资源确认单元504,用于在所述子网节点属于第二子任务的参与方节点的情况下,基于第二租户的租户标识从所述租户权限合约中确定出第二租户在所述多份可调用资源中对应的第二可调用资源。所述资源调用单元502具体用于:在第二可调用资源不为第一可调用资源的情况下,分别调用第一可调用资源与第二可调用资源并行执行第一子任务与第二子任务;在第二可调用资源为第一可调用资源的情况下,调用第一可调用资源串行执行第一子任务与第二子任务。
可选的,还包括:临时资源调用单元505,用于在无法从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源的情况下,从所述多份可调用资源中确定出支持第一子任务对应的资源需求的第三可调用资源,并调用第三可调用资源执行第一子任务。
可选的,还包括:权限更新单元506,用于通过所述主网节点向所述租户权限合约发起权限变更交易,以使所述租户权限合约维护有第一租户与第三可调用资源之间的对应关系。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等,目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然,本发明不排除随着未来计算机技术的发展,实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的装置或终端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境,甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下,并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一,第二等词语用来表示名称,而并不表示任何特定的顺序。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现,也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令 装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
本领域技术人员应明白,本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已,并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说,本说明书一个或多个实施例可以有各种 更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在权利要求范围之内。

Claims (13)

  1. 一种可调用资源的分配方法,应用于部署有主网节点与子网节点的节点设备,所述子网节点所处的区块链子网由所述主网节点所处的区块链主网所管理,所述节点设备部署有多份可调用资源,所述区块链主网部署有租户权限合约,所述租户权限合约维护有各租户与所述多份可调用资源之间的对应关系,所述区块链子网部署有任务合约;所述方法包括:
    监听所述任务合约生成的子任务事件,所述子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息;
    在所述子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。
  2. 根据权利要求1所述的方法,所述任务合约维护有第一任务对应的任务完成状态;所述监听所述任务合约生成的子任务事件,包括:
    监听所述任务合约在第一任务对应的任务完成状态满足第一任务包含的第一子任务对应的执行条件的情况下生成的所述子任务事件。
  3. 根据权利要求2所述的方法,还包括:
    在第一子任务执行完毕的情况下,通过所述子网节点向所述任务合约发起包含第一子任务对应的执行结果的结果返回交易,以更新所述任务合约维护的第一任务对应的任务完成状态。
  4. 根据权利要求1所述的方法,所述任务合约维护有至少一个租户各自发起的多个任务分别对应的任务完成状态。
  5. 根据权利要求1所述的方法,所述调用第一可调用资源执行第一子任务,包括:
    在第一可调用资源支持第一子任务对应的资源需求的情况下,调用第一可调用资源执行第一子任务,所述资源需求的类型包括:计算需求、数据引擎需求和/或数据输入需求。
  6. 根据权利要求1所述的方法,所述可调用资源的类型包括:计算引擎、数据引擎和/或数据源。
  7. 根据权利要求1所述的方法,所述租户权限合约维护的所述各租户与所述多份可调用资源之间的对应关系由所述租户权限合约响应于权限变更交易触发更新。
  8. 根据权利要求1所述的方法,所述子任务事件还包括:第二租户的租户标识与第二租户发起的第二子任务的参与方节点的描述信息;所述方法还包括:
    在所述子网节点属于第二子任务的参与方节点的情况下,基于第二租户的租户标识从所述租户权限合约中确定出第二租户在所述多份可调用资源中对应的第二可调用资源;
    所述调用第一可调用资源执行第一子任务,包括:
    在第二可调用资源不为第一可调用资源的情况下,分别调用第一可调用资源与第二可调用资源并行执行第一子任务与第二子任务;在第二可调用资源为第一可调用资源的情况下,调用第一可调用资源串行执行第一子任务与第二子任务。
  9. 根据权利要求1所述的方法,还包括:
    在无法从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源的情况下,从所述多份可调用资源中确定出支持第一子任务对应的资源需求的第三可调用资源,并调用第三可调用资源执行第一子任务。
  10. 根据权利要求9所述的方法,还包括:
    通过所述主网节点向所述租户权限合约发起权限变更交易,以使所述租户权限合约维护有第一租户与第三可调用资源之间的对应关系。
  11. 一种可调用资源的分配装置,应用于部署有主网节点与子网节点的节点设备, 所述子网节点所处的区块链子网由所述主网节点所处的区块链主网所管理,所述节点设备部署有多份可调用资源,所述区块链主网部署有租户权限合约,所述租户权限合约维护有各租户与所述多份可调用资源之间的对应关系,所述区块链子网部署有任务合约;所述装置包括:
    事件监听单元,用于监听所述任务合约生成的子任务事件,所述子任务事件包括第一租户的租户标识与第一租户发起的第一子任务的参与方节点的描述信息;
    资源调用单元,用于在所述子网节点属于第一子任务的参与方节点的情况下,基于第一租户的租户标识从所述租户权限合约中确定出第一租户在所述多份可调用资源中对应的第一可调用资源,并调用第一可调用资源执行第一子任务。
  12. 一种电子设备,包括:
    处理器;
    用于存储处理器可执行指令的存储器;
    其中,所述处理器通过运行所述可执行指令以实现如权利要求1至10中任一项所述的方法。
  13. 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1至10中任一项所述方法的步骤。
PCT/CN2022/135203 2022-03-31 2022-11-30 一种可调用资源的分配方法和装置 WO2023185043A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210344003.1A CN114710350B (zh) 2022-03-31 2022-03-31 一种可调用资源的分配方法、装置、电子设备和存储介质
CN202210344003.1 2022-03-31

Publications (1)

Publication Number Publication Date
WO2023185043A1 true WO2023185043A1 (zh) 2023-10-05

Family

ID=82172320

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135203 WO2023185043A1 (zh) 2022-03-31 2022-11-30 一种可调用资源的分配方法和装置

Country Status (2)

Country Link
CN (1) CN114710350B (zh)
WO (1) WO2023185043A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114710350B (zh) * 2022-03-31 2024-04-02 蚂蚁区块链科技(上海)有限公司 一种可调用资源的分配方法、装置、电子设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112866212A (zh) * 2021-01-04 2021-05-28 北京金山云网络技术有限公司 云计算资源的访问控制方法、装置、计算机设备和介质
CN114116166A (zh) * 2021-06-02 2022-03-01 支付宝(杭州)信息技术有限公司 基于智能合约的任务执行方法及装置
CN114710350A (zh) * 2022-03-31 2022-07-05 蚂蚁区块链科技(上海)有限公司 一种可调用资源的分配方法和装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190058709A1 (en) * 2017-08-16 2019-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Tenant management method and system in a cloud computing environment
CN113067901B (zh) * 2021-06-02 2021-09-24 支付宝(杭州)信息技术有限公司 区块链子网的创建方法
CN113067895B (zh) * 2021-06-02 2021-08-31 支付宝(杭州)信息技术有限公司 组建区块链子网的方法和区块链系统
CN113259464B (zh) * 2021-06-02 2021-11-02 支付宝(杭州)信息技术有限公司 组建区块链子网的方法和区块链系统
CN113259466B (zh) * 2021-06-02 2021-10-15 支付宝(杭州)信息技术有限公司 区块链子网运行状态的控制方法和区块链系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112866212A (zh) * 2021-01-04 2021-05-28 北京金山云网络技术有限公司 云计算资源的访问控制方法、装置、计算机设备和介质
CN114116166A (zh) * 2021-06-02 2022-03-01 支付宝(杭州)信息技术有限公司 基于智能合约的任务执行方法及装置
CN114710350A (zh) * 2022-03-31 2022-07-05 蚂蚁区块链科技(上海)有限公司 一种可调用资源的分配方法和装置

Also Published As

Publication number Publication date
CN114710350B (zh) 2024-04-02
CN114710350A (zh) 2022-07-05

Similar Documents

Publication Publication Date Title
WO2019090523A1 (zh) 一种无服务器架构下业务部署的方法和函数管理平台
CN108134764B (zh) 一种分布式数据共享交换方法及系统
WO2020024650A1 (zh) 数据处理方法和装置、客户端
CN113067901B (zh) 区块链子网的创建方法
WO2024001022A1 (zh) 跨子网调用
CN113067897B (zh) 跨链交互方法及装置
CN113067895B (zh) 组建区块链子网的方法和区块链系统
WO2022252996A1 (zh) 为业务流程合约调度计算服务的方法
WO2023131058A1 (zh) 一种企业数字中台中资源服务应用的调度系统和方法
WO2023185043A1 (zh) 一种可调用资源的分配方法和装置
WO2023050966A1 (zh) 验证区块链数据
WO2023050986A1 (zh) 维护区块链系统的网络架构信息
CN114363162B (zh) 区块链日志的生成方法及装置、电子设备、存储介质
CN113259120B (zh) 同步节点信息列表的方法
CN113067914B (zh) 一种分配子网标识的方法、装置、电子设备和存储介质
CN113259117B (zh) 同步节点信息列表的方法
CN113259118B (zh) 同步节点信息列表的方法
WO2023207076A1 (zh) 区块链子网的组建方法及装置
WO2022252993A1 (zh) 基于链外计算服务的业务执行方法
WO2023207077A1 (zh) 区块链节点的迁移方法及装置
CN114363335B (zh) 跨链交互方法及装置
CN113259459B (zh) 区块链子网运行状态的控制方法和区块链系统
CN113067838B (zh) 跨链交互方法及装置
CN113259466B (zh) 区块链子网运行状态的控制方法和区块链系统
CN113259237B (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: 22934861

Country of ref document: EP

Kind code of ref document: A1