Blockchain Resource Management Method and Device Based on Multi-Chain Collaboration

Abstract

The present invention provides a blockchain resource management method and apparatus based on multi-chain collaboration, which can be used in the financial field or other technical fields. The method includes: determining the request type of a resource call request according to the request content of the resource call request, where the resource call request includes information of a resource caller; if the request type of the resource call request is a smart contract request, locally executing the smart contract requested to be executed in the resource call request according to the service parameters in the resource call request; sending the resource call request to a main chain node, where the main chain node is used to verify whether the resource caller has the execution permission of the smart contract; generating a response message for the resource call request according to the execution result of the smart contract and the verification result generated by the main chain node. The apparatus is used to execute the above method. The blockchain resource management method and apparatus based on multi-chain collaboration provided by the embodiments of the present invention improve the response speed of the blockchain system to transactions.

Description

Technical Field

[0001] The present invention relates to the field of finance or other technologies, and particularly to a blockchain resource management method and device based on multi-chain collaboration. Background Art

[0002] Currently, the main blockchain-based permission management methods are as follows: Permission management based on a single-chain single smart contract, which mainly relies on the smart contract mechanism originally available in the blockchain. The permission control function is implemented by expanding the function of the smart contract according to the contract mechanism, and the permission control scope mainly focuses on the call permission of functions related to a certain smart contract. Permission management based on a single-chain multiple smart contracts. This type of permission management mechanism has similarities with the first permission management method, that is, the permission management mechanism is still implemented through the smart contract mechanism of the blockchain. However, the difference is that this solution directly divides the smart contract function into two parts, one for business implementation and the other for permission management. The smart contract for permission management is independent of the smart contract for business implementation, but the smart contract for business implementation can communicate with the smart contract for permission management through a certain communication mechanism and determine the legitimacy of the permission based on the result.

[0003] The current permission management method integrates the permission control mechanism of relevant resources on a blockchain system with a single-chain architecture, which limits the response speed of the blockchain system to transactions and makes the system unable to efficiently process transactions. Summary of the Invention

[0004] In view of the problems in the prior art, embodiments of the present invention provide a blockchain resource management method and device based on multi-chain collaboration, which can at least partially solve the problems existing in the prior art.

[0005] On the one hand, the present invention proposes a blockchain resource management method based on multi-chain collaboration, including:

[0006] Determine the request type of the resource call request according to the request content of the resource call request, where the resource call request includes information about the resource caller;

[0007] If the request type of the resource call request is a smart contract request, execute the smart contract requested to be executed in the resource call request locally according to the business parameters in the resource call request;

[0008] Send the resource call request to the main chain node, where the main chain node is used to verify whether the resource caller has the execution permission of the smart contract;

[0009] Generate the response information of the resource call request according to the execution result of the smart contract and the verification result generated by the main chain node.

[0010] On the other hand, the present invention proposes a blockchain resource management method based on multi-chain collaboration, including:

[0011] Obtain a resource invocation request forwarded by a side-chain node, where the resource invocation request includes information about the resource invoker;

[0012] If the request type of the resource invocation request is a smart contract request, then verify whether the resource invoker has the execution permission of the smart contract to be executed in the resource invocation request according to the resource permission information stored locally;

[0013] Send the verification result to the side-chain node, where the side-chain node is used to generate response information for the resource invocation request according to the verification result and the execution result of the smart contract on the side-chain node.

[0014] In yet another aspect, an embodiment of the present invention provides a blockchain resource management device based on multi-chain collaboration, including:

[0015] A determination module, configured to determine the request type of the resource invocation request according to the request content of the resource invocation request, where the resource invocation request includes information about the resource invoker;

[0016] An execution module, configured to, if the request type of the resource invocation request is a smart contract request, execute the smart contract to be executed in the resource invocation request locally according to the service parameters in the resource invocation request;

[0017] A sending module, configured to send the resource invocation request to a main-chain node, where the main-chain node is used to verify whether the resource invoker has the execution permission of the smart contract;

[0018] A generation module, configured to generate response information for the resource invocation request according to the execution result of the smart contract and the verification result generated by the main-chain node.

[0019] In still another aspect, an embodiment of the present invention provides a blockchain resource management device based on multi-chain collaboration, including:

[0020] An acquisition module, configured to acquire a resource invocation request forwarded by a side-chain node, where the resource invocation request includes information about the resource invoker;

[0021] A verification module, configured to, if the request type of the resource invocation request is a smart contract request, verify whether the resource invoker has the execution permission of the smart contract to be executed in the resource invocation request according to the resource permission information stored locally;

[0022] A sending module, configured to send the verification result to the side chain node, where the side chain node is configured to generate response information of the resource call request according to the verification result and the execution result of the smart contract on the side chain node.

[0023] An embodiment of the present invention further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the blockchain resource management method based on multi-chain collaboration described in any of the above embodiments are implemented.

[0024] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the blockchain resource management method based on multi-chain collaboration described in any of the above embodiments are implemented.

[0025] The blockchain resource management method and device based on multi-chain collaboration provided by the embodiments of the present invention adopt a multi-chain architecture to construct a blockchain permission management mechanism, and run the permission management mechanism and the smart contract mechanism on different chains, realizing the independence of the blockchain system permission control mechanism and business rules, reducing the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system, and improving the response speed of the blockchain system to transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts. In the drawings:

[0027] Figure 1 is the core logic topology diagram of the blockchain resource management system based on multi-chain collaboration provided by an embodiment of the present invention.

[0028] Figure 2 is the main component module diagram of the blockchain resource management system based on multi-chain collaboration provided by an embodiment of the present invention.

[0029] Figure 3 is the flow schematic diagram of the blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention.

[0030] Figure 4 is the partial flow schematic diagram of the blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention.

[0031] Figure 5It is a partial process schematic diagram of a blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention.

[0032] Figure 6 It is a process schematic diagram of a blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention.

[0033] Figure 7 It is a partial process schematic diagram of a blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention.

[0034] Figure 8 It is a flowchart of the response process of a permission management request for a blockchain resource management system based on multi-chain collaboration provided by an embodiment of the present invention.

[0035] Figure 9 It is a flowchart of the response process of a smart contract request for a blockchain resource management system based on multi-chain collaboration provided by an embodiment of the present invention.

[0036] Figure 10 It is a schematic structural diagram of a blockchain resource management device based on multi-chain collaboration provided by an embodiment of the present invention.

[0037] Figure 11 It is a schematic structural diagram of a blockchain resource management device based on multi-chain collaboration provided by an embodiment of the present invention.

[0038] Figure 12 It is a schematic physical structure diagram of an electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0039] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer and more understandable, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but not to limit the present invention. It should be noted that, without conflict, the embodiments and features in the embodiments of the present application can be arbitrarily sorted with each other.

[0040] Regarding the "first", "second",... used herein, they do not particularly refer to the meaning of order or sequence, nor are they used to limit the present invention. They are only used to distinguish elements or operations described with the same technical terms.

[0041] Regarding the "including", "comprising", "having", "containing", etc. used herein, they are all open-ended terms, that is, they are meant to include but not limited to.

[0042] Regarding the "and / or" used herein, it includes any or all of the listed things in any order.

[0043] To better understand the present invention, the research background and overall implementation architecture of the present invention will be introduced as follows:

[0044] Both of the two solutions mentioned in the background art of the present invention implement the permission mechanism inside the blockchain through the smart contract mechanism of the blockchain system. Compared with the first solution, the permission management function in the second solution can be more independent, realizing the one-to-many mode of permission management. However, the permission management in the blockchain system not only includes smart contracts, but also includes permissions at the system itself level, such as permissions for interface resources and node user permissions. The permission control mechanisms implemented based on smart contracts in the two solutions cannot further regulate the permissions of this part of resources.

[0045] Moreover, most of the current permission management methods are implemented in the single-chain architecture of the blockchain. Currently, the blockchain system has bottlenecks in performance, capacity, isolation, and scalability in the single-chain architecture. Integrating the permission control mechanism of relevant resources on the blockchain system with a single-chain architecture may further limit the response speed of the blockchain system to transactions, making the system unable to process transactions efficiently.

[0046] Aiming at the disadvantages of the existing technical solutions, the present invention aims to design a blockchain resource management method and system based on multi-chain collaboration for the blockchain system (mainly the consortium blockchain system). By introducing mechanisms such as permission control plugins and certificate-based permission authentication in the multi-chain architecture of the blockchain, on the one hand, it realizes the independence of the permission control mechanism and business rules of the blockchain system and uniformly controls the permissions of multi-level resources in the blockchain system. On the other hand, it reduces the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system, breaking through the bottlenecks in the scalability and performance of the blockchain system. Among them,

[0047] Multi-chain collaboration: In a blockchain network, there are two or more blockchains. These chains belong to the same network, but on the one hand, they have independent functions, and on the other hand, they can communicate with each other through a certain communication mechanism and jointly complete a certain function.

[0048] Smart contract: A smart contract is the specific code implementation of business rules on the blockchain system. The executable code defines the rules between different organizations. The application program calls the smart contract to generate transactions that are recorded in the ledger.

[0049] Permission control plugin: This plugin is a built-in program of the blockchain system, independent of the smart contract mechanism of the system itself. The permission control plugin can access all the resources of the blockchain system itself, and the permission control plugin can obtain blocks or update blocks through consensus in the blockchain network.

[0050] The blockchain resource management method and system based on multi-chain collaboration provided by the present invention separate permission management and business implementation in a multi-chain mode. The main chain is responsible for functions such as block consensus, permission management and control. On the one hand, a permission control plugin is introduced to uniformly manage system interfaces and permissions related to smart contracts. On the other hand, the main chain uses a certificate-based permission authentication mechanism to judge the legality of permission requests related to side chains. And the side chain implements the execution of business logic according to the permission control situation of relevant resources in the main chain.

[0051] Figure 1 It is the core logic topology diagram of a blockchain resource management system based on multi-chain collaboration provided by the present invention.

[0052] "User 11" can be institutional and individual users who call the system, and the calling method can be a restful interface or a grpc interface. The interfaces that "User 11" can call are mainly divided into two categories. One category is the interfaces that trigger the execution of smart contracts, such as executing a certain function of a smart contract. The other category is the interfaces that operate other resources of the system, such as obtaining block content and managing user permissions.

[0053] "Blockchain node 12" is the main component of the system. This type of node is responsible for receiving and processing requests from "User 11", reaching a consensus on transaction content and permission management content, and performing the operation of putting the block on the chain. Logically, blockchain nodes can be divided into two sub-categories: accounting nodes and consensus nodes. In actual deployment, the same physical node can be both an accounting node and a consensus node at the same time. There can be multiple "chain-like" data structures on "blockchain node 12" that can put blocks on the chain. In this system, there are two types of "chain-like" data structures on "blockchain node 12", one is called "main chain 13", and the other is called "side chain 14".

[0054] The block information on the "main chain 13" is all related to the permissions of various resources in the blockchain system. The blocks on the "main chain 13" are mainly divided into two types. One is the resource access permission information within the blockchain system, and the other is the smart contract permission information and user permission information. Before the system initialization, it is necessary to determine the current system resource access permission information and put this information into the genesis block of the "main chain 13".

[0055] The block information on the "side chain 14" is mainly related to specific scenario data. In addition, there is a block on the "side chain 14" that records the latest resource access permission information of the current blockchain system. This block is pushed from the "main chain 13" after initialization or after a new block is added to the "main chain 13".

[0056] "CA Node 15" is the certificate issuing node of the blockchain system. It will issue digital certificates for nodes based on the templates and public keys sent by the nodes, providing a verification method for mutual recognition between nodes and permission authentication between the main chain and the side chain. The root certificate possessed by this node can be an authoritative third-party certificate in the industry.

[0057] Figure 2 It is the main component module diagram of this system, including "Request Acceptance Module 21", "First Permission Control Module 22", "Second Permission Control Module 23", "Communication Module 24", "Smart Contract Module 25", "Consensus Module 26", "Storage Module 27".

[0058] "Request Acceptance Module 21" is used by "Blockchain Node 12" or "CA Node 15" to receive requests from "User 11". For "Blockchain Node 12", this module will extract information such as the request type, user ID, smart contract ID, and smart contract operation of the request, package and encapsulate them into an internal communication message, and broadcast this message among each node; for "CA Node 15", this module will extract the templates and public keys sent by the node in the request, and generate digital certificates for the node according to the templates.

[0059] "First Permission Control Module 22" belongs to the first part of the permission control plugin introduced in this system. The execution of this module depends on the resource access permission information on the side chain regarding the current blockchain system. According to the resource access permission information, this module determines whether the current user has the permission to access specific resources. For example, this module can determine whether a certain user has the permission to access a certain interface.

[0060] "Second Permission Control Module 23" belongs to the second part of the permission control plugin introduced in this system. The execution of this module mainly falls into two categories: one is for permission judgment. By obtaining the mapping relationship between a certain smart contract, a certain user, and related roles on the main chain, "Second Permission Control Module 23" can determine whether the current user has the permission to perform operations related to a certain smart contract. For example, this module can determine whether a certain user has the permission to upgrade a certain smart contract; the other is for permission update. A legitimate "User 11" can perform addition, deletion, query, and modification of the permission control information regarding resources on the main chain through an interface. For example, a certain user can perform addition, deletion, query, and modification of the permissions for a certain smart contract operation.

[0061] "Communication Module 24" defines relevant messages for the communication between "Second Permission Control Module 23" and "Smart Contract Module 25" and provides means for their respective communications. During the design process of this system, there are mainly two communication modes. One is that the "Smart Contract Module 25" on the side chain obtains the permission legality of a certain user regarding a certain smart contract on the main chain, and the other is that after the main chain adds or updates the resource access permission information in the blockchain system through "Second Permission Control Module 23", it pushes the corresponding block to the side chain.

[0062] "Smart contract module 25" is a mechanism in the blockchain system that executes specific operations of smart contracts, ensuring that the execution of smart contracts is independent of the operation of the node itself. This module provides a series of default functions for developing smart contracts, and specific business rules can be assembled and implemented based on the provided functions.

[0063] "Consensus module 26" defines the specific algorithm for each node in the blockchain system to reach a consensus, while "storage module 27" is mainly used by "blockchain node 12" to store or persist the blocks of the main chain and side chains on its own node in the blockchain system. "Blockchain node 12" will pack a certain number of transactions into a block according to specific block-packing rules and reach a consensus among nodes. After each node reaches a consensus, each node will call "storage module 27" to append the latest block to the main chain or side chain on its own node.

[0064] "Certificate issuance module 28" is a built-in function module of the CA node. This module is responsible for issuing digital certificates to nodes. "Blockchain node 12" can specify the role of the node in the certificate template, and the specified role information will be reflected in the issued digital certificate.

[0065] Figure 3 It is a schematic flowchart of a blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention, which is applied to side chain nodes, such as Figure 3 As shown, the blockchain resource management method based on multi-chain collaboration provided by the embodiment of the present invention includes:

[0066] S101. Determine the request type of the resource call request according to the request content of the resource call request, where the resource call request includes information about the resource caller.

[0067] In step S101, the resource call request can be initiated by the resource caller (user) through the restful interface or grpc interface, and the request content includes the ID (identity information) of the resource caller, the signature string of the request message by the resource caller, and other contents.

[0068] When the side chain node receives this request, it can first verify the signature of the request. If the signature verification passes, it determines the request type of the resource call request according to the request content of the resource call request. Specifically, when the resource call request requests to execute a smart contract, it determines that the request type of this request is a smart contract request; when the resource call request requests to manage resource permissions, it determines that the request type of this request is a permission management request. The request type can be judged by a certain field in the request, or by a predefined ID to determine what type of request it is.

[0069] S102. If the request type of the resource invocation request is a smart contract request, execute the smart contract requested to be executed in the resource invocation request according to the service parameters in the resource invocation request on the local side;

[0070] In step S102, according to the service parameters in the request, execute the smart contract requested to be executed in the resource invocation request on the local side to obtain an execution result.

[0071] S103. Send the resource invocation request to the main chain node, where the main chain node is used to verify whether the resource invoker has the execution permission for the smart contract;

[0072] In step S103, the side chain node sends the resource invocation request to the main chain node. The main chain node obtains the block on the main chain that records the mapping relationship between the smart contract, the invoker ID, and the relevant roles of the invoker according to the smart contract ID and the resource invoker ID in the request, and compares it with the invoker ID that sends the smart contract request, so as to judge whether the resource invoker has the permission to perform the relevant operations of the smart contract. The processes described in step S103 and step S102 are independent of each other and are executed in parallel.

[0073] S104. Generate the response information of the resource invocation request according to the execution result of the smart contract and the verification result generated by the main chain node.

[0074] In step S104, if the verification result is that the resource invoker has the execution permission for the smart contract, pack the execution result of the smart contract into a block and conduct consensus among the side chain nodes. After the new block is consensus, append the new block to the side chain. That is, after the nodes on the side chain complete the new block on the chain, they will feedback the response situation of the smart contract request to the resource invoker, that is, the execution result of the smart contract. If the verification result is that the resource invoker does not have the execution permission for the smart contract, feedback an execution error to the resource invoker, that is, notify the resource invoker that it has no permission to execute the smart contract.

[0075] The blockchain resource management method based on multi-chain collaboration provided by the embodiments of the present invention constructs a blockchain permission management mechanism in the form of a multi-chain architecture, runs the permission management mechanism and the smart contract mechanism on different chains, realizes the independence of the permission control mechanism and the business rules of the blockchain system, reduces the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system, and improves the response speed of the blockchain system to transactions.

[0076] As Figure 4 shown, in an optional embodiment of the present invention, the determining the request type of the resource invocation request according to the request content of the resource invocation request includes:

[0077] S1011. Determine whether the resource invoker has the permission to access the resource requested to be invoked in the resource invocation request according to the latest resource access permission information stored locally, where the latest resource access permission information stored locally is obtained from the main chain node in advance;

[0078] In step S1011, the resource access permission information includes the mapping relationship between the resource and the invokers with access permissions. The resource access permission information is managed by the main chain node, and the latest resource access permission information is saved on the side chain node.

[0079] S1012. If the resource invoker has the permission to access the resource requested to be invoked in the resource invocation request, determine the request type of the resource invocation request according to the resource requested to be invoked.

[0080] In step S1012, the method for determining the request type of the resource invocation request according to the resource requested to be invoked is similar to the method in step S101 above, and will not be elaborated here.

[0081] As Figure 5 shown, in an optional embodiment of the present invention, the determining whether the resource invoker has the permission to access the resource requested to be invoked in the resource invocation request according to the latest resource access permission information stored locally includes:

[0082] S10111. Search for the invoker role type corresponding to the resource requested to be invoked in the latest resource access permission information stored locally;

[0083] In step S10111, it is assumed that the default resource invoker and each node in the blockchain network have obtained legal digital certificates through the CA node. This type of certificate contains the role type of the resource invoker or node, and this role type determines whether the resource invoker or node can access the corresponding resource. When the side chain node receives a request, it first obtains the invoker's certificate according to the invoker ID, extracts the role type owned by the invoker from the certificate. Then it obtains the block recording the current blockchain system resource access permission information from the side chain, retrieves the permission policy that the corresponding resource needs to meet for the resource involved in this request in the obtained block, and compares it with the role type recorded in the invoker's certificate, so as to determine whether the invoker has the permission to access the resource involved in the request.

[0084] Among them, the side chain node can obtain the invoker's certificate from the CA node according to the invoker ID; or obtain it from the memory of the current node. During the consensus process, the node can save the certificates of other authentication nodes in the memory.

[0085] S10112. If the role type is the same as the role type recorded in the certificate information of the resource invoker, it is determined that the resource invoker has the permission to access the requested resource.

[0086] In step S10112, if the role type of the invoker corresponding to the requested resource is the same as the role type recorded in the certificate information of the resource invoker, it is determined that the resource invoker has the permission to access the requested resource.

[0087] In an optional embodiment of the present invention, the method further includes: if the request type of the resource invocation request is a permission management request, sending the resource invocation request to the main chain node, where the main chain node is used to update the resource permission information to be managed in the resource invocation request according to the resource invocation request.

[0088] In this embodiment, the main chain node manages the permission information. When the side chain node determines that the request type of the resource invocation request is a permission management request, such as a smart contract permission management request or a user permission management request, the resource invocation request is forwarded to the main chain node. The main chain node updates the resource permission information to be managed in the resource invocation request according to the resource invocation request, and puts the updated resource permission information into a new block. After the new block is consensus, the main chain node appends the new block to the main chain.

[0089] Optionally, in the above embodiment, if the resource permission information updated by the main chain node includes resource access permission information, the method may further include: obtaining and saving the updated resource access permission information pushed by the main chain node.

[0090] In this embodiment, if the permission management request involves the permission information (resource access permission information) of the overall resources of the system, after the main chain node uploads the new block to the chain, it pushes the new block to the side chain. However, if the permission management request involves the permissions related to smart contract operations, the new block will not be pushed to the side chain. After receiving the new block pushed by the main chain, the side chain node appends the new block to the side chain.

[0091] Optionally, the step of if the request type of the resource invocation request is a permission management request, sending the resource invocation request to the main chain node, where the main chain node is used to update the resource permission information to be managed in the resource invocation request according to the resource invocation request includes:

[0092] If the request type of the resource invocation request is a permission management request, sending the identity information of the local side chain node and the resource invocation request to the main chain node, where the main chain node is used to update the resource permission information to be managed in the resource invocation request according to the identity information of the side chain node and the resource invocation request.

[0093] In this embodiment, if the request type of the resource invocation request is a permission management request, the side chain node will add the ID of this node to the original request and then forward the request to the main chain node. The main chain node obtains the resource permission information to be managed by the request locally. For example, the resource permission information may be a list of legitimate users for the corresponding operations of the resource. The main chain node updating the resource permission information to be managed in the resource invocation request may include: the main chain node adds the ID of the resource invoker to the list and puts the updated list into a new block. After the new block is consensus-approved, the main chain node appends the new block to the main chain.

[0094] After the side chain node receives the new block pushed by the main chain node and completes the on-chain of the new block or receives the main chain response, it will feedback the response situation of the permission management request to the resource invoker.

[0095] Figure 6 is a schematic flowchart of a blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention, which is applied to the main chain node. As Figure 6 shown, the blockchain resource management method based on multi-chain collaboration provided by the embodiment of the present invention includes:

[0096] S201. Obtain a resource invocation request forwarded by a side chain node, where the resource invocation request includes information of a resource invoker;

[0097] In step S201, after receiving the resource invocation request, the side chain node forwards the resource invocation request to the main chain node. The resource invocation request includes information of the resource invoker, such as the ID of the resource invoker.

[0098] S202. If the request type of the resource invocation request is a smart contract request, verify whether the resource invoker has the execution permission of the smart contract to be executed by the resource invocation request according to the resource permission information stored locally;

[0099] In step S202, the main chain node determines the request type of the resource invocation request according to the request content of the resource invocation request. Specifically, when the resource invocation request requests to execute a smart contract, it is determined that the request type of the request is a smart contract request. When the resource invocation request requests to manage resource permissions, it is determined that the request type of the request is a permission management request. The type of the request can be judged by a certain field in the request or according to a predefined ID.

[0100] If the request type of the resource invocation request is a smart contract request, the main chain node obtains the block on the main chain that records the mapping relationship between the smart contract, the invoker ID, and the relevant roles of the invoker according to the smart contract ID and the resource invoker ID in the request, and compares it with the invoker ID that sent the smart contract request, so as to determine whether the resource invoker has the permission to execute the relevant operations of the smart contract.

[0101] S203. Send the verification result to the side chain node, where the side chain node is used to generate the response information of the resource invocation request according to the verification result and the execution result of the smart contract on the side chain node.

[0102] In step S203, if the verification result is that the resource invoker has the execution permission of the smart contract, the execution result of the smart contract is packaged into a block and consensus is carried out among the side chain nodes. After the new block is consensus, the new block is appended to the side chain. That is, after the nodes on the side chain complete the new block on-chain, they will feedback the response situation of the smart contract request to the resource invoker, that is, the execution result of the smart contract. If the verification result is that the resource invoker does not have the execution permission of the smart contract, an execution error is feedback to the resource invoker, that is, it is notified that the resource invoker has no permission to execute the smart contract.

[0103] The blockchain resource management method based on multi-chain collaboration provided by the embodiments of the present invention constructs a blockchain permission management mechanism in the form of a multi-chain architecture, runs the permission management mechanism and the smart contract mechanism on different chains, realizes the mutual independence of the permission control mechanism and business rules of the blockchain system, reduces the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system, and improves the response speed of the blockchain system to transactions.

[0104] Such as Figure 7 As shown, optionally, after obtaining the resource invocation request forwarded by the side chain node, the method further includes:

[0105] S204. If the request type of the resource invocation request is a permission management request, verify whether the side chain node has the permission to manage the resource permission information requested to be managed in the resource invocation request according to the locally stored resource permission information;

[0106] In step S204, if the request type of the resource invocation request is a permission management request, the side chain node will add the ID of the current node to the original request and then forward the request to the main chain node. The main chain node first obtains the ID of the forwarding node from the request, and then determines whether the forwarded node has the permission to manage the resource permission information.

[0107] S205: If the side chain node has the authority to manage the resource permission information requested to be managed in the resource call request, update the resource permission information requested to be managed in the resource call request according to the resource call request.

[0108] In step S205, when the side-chain node has the authority to manage the resource permission information requested in the resource call request, the main-chain node updates the resource permission information requested in the resource call request according to the resource call request. For example, the main-chain node updating the resource permission information requested in the resource call request may include: the main-chain node adding the ID of the resource caller to the list of legal users of a certain resource, and placing the updated list into a new block. After the new block reaches consensus, the main-chain node appends the new block to the main chain.

[0109] Optionally, the method further includes: if the updated resource permission information includes resource access permission information, pushing the resource access permission information to the side chain node.

[0110] In this embodiment, if the permission management request involves permission information (resource access rights information) for the entire system's resources, the mainchain node will push the new block to the sidechain after uploading it. However, if the permission management request involves permissions for smart contract-related operations, the new block will not be pushed to the sidechain. After receiving the new block pushed by the mainchain, the sidechain node will append the new block to the sidechain.

[0111] The following is an explanation of a blockchain resource management method based on multi-chain collaboration provided by the present invention through specific embodiments:

[0112] Figure 8 This is a flowchart of the response process of the permission management request based on the system. The following processes assume that "11 user" and "blockchain node 12" have obtained legal digital certificates through "15CA node". This type of certificate contains the role type of the user or node, and the role type determines whether the user or node can access the corresponding resources.

[0113] In step S301, "user 11" initiates a rights management request to "blockchain node 12" through the restful interface or grpc interface. The request content includes the user's ID, the signature string of the rights management request message of "user 11", and other contents.

[0114] Step S302. When the "blockchain node 12" on the side chain receives a request, the node calls the "first permission control module 22" to judge the resource access permission. In the first step, this module first obtains the user's certificate according to the user ID and verifies the signature of the request. If the signature verification passes, the "first permission control module 22" extracts the role type owned by the user from the certificate. In the second step, this module then obtains the block on the side chain that records the overall resource permission control information (resource access permission information) of the current blockchain system, retrieves the permission policy that the corresponding resource needs to meet in the obtained block according to the resource involved in the request, and compares it with the role type recorded in the user certificate, so as to judge whether "user 11" has the permission to call the resources involved in the permission management request.

[0115] Step S303. After the request passes through "Step S302", the "blockchain node 12" judges the request type to determine whether the request belongs to a business smart contract request or a permission management request. If it is a permission management request, the "blockchain node 12" will add the ID of this "blockchain node 12" to the original request and then forward the request to the main chain.

[0116] Step S304. When the "blockchain node 12" on the main chain receives a permission management request, it will first call the "second permission control module 23" to verify the management permission of the forwarding node. This module first obtains information such as the ID of the forwarding node and the resource type from the request, and then obtains the block on the main chain that records the mapping relationship between the resource, the user and the relevant roles, so as to judge whether the forwarded node has the permission to manage the entire life cycle of this resource.

[0117] Step S305. If the forwarded node has the permission to manage the entire life cycle of this resource, the "blockchain node 12" on the main chain calls the "second permission control module 23" according to the resources and smart contract operations in the permission management request to obtain the list of legitimate users for this resource and the corresponding operations, adds the ID of "user 11" to this list, and puts the updated list into a new block. After the new block is consensus, the "blockchain node 12" on the main chain will call the "storage module 27" to append the new block to the main chain.

[0118] Step S306. If the permission management request involves the permission control information of the overall resources of this system, after the "blockchain node 12" uploads the new block to the chain, it calls the "communication module 24" to push the new block to the side chain. However, if the permission management request involves the permission of smart contract related operations, the "blockchain node 12" will not push the new block to the side chain.

[0119] Step S307. After the "blockchain node 12" on the side chain receives the new block pushed by the main chain, it will call the "storage module 27" to append the new block to the side chain.

[0120] Step S308: After the "blockchain node 12" on the side chain completes the new block on the chain or receives the response from the main chain, the "blockchain node 12" will feedback the response status of the permission management request to "user 11".

[0121] Figure 9 This is a flow chart of the response process of smart contract requests based on this system.

[0122] In step S401, "User 11" initiates a smart contract request to "Blockchain Node 12" on the side chain through the restful interface or grpc interface. The request content includes the user's ID, "User 11"'s signature string for the smart contract request message, and other content.

[0123] Step 402 is the same as the above-mentioned "step S302", that is, the "blockchain node 12" on the side chain performs resource access permission judgment through the "first permission control module 22" to determine whether the current "user 11" has the permission to call the smart contract.

[0124] Step S403: After the request passes Step S402, Blockchain Node 12 on the sidechain determines the request type, determining whether it is a business smart contract request or a permissions management request. If it is a business smart contract request, Blockchain Node 12 triggers two processes: one for smart contract execution on the sidechain and one for smart contract execution permissions verification on the mainchain.

[0125] Step S404: Blockchain Node 12 on the main chain triggers the smart contract execution permission verification process. This process occurs on the main chain. Based on the smart contract ID and user ID in the smart contract request, Blockchain Node 12 calls the Second Permission Control Module 23 to obtain the block on the main chain that records the mapping relationship between the smart contract, relevant role types, and authorized users. This block is then compared with the user ID that triggered the smart contract request to determine whether User 11 has permission to execute the relevant operations of the smart contract.

[0126] Step S405: Smart contract execution process triggered by "blockchain node 12" on the sidechain. This process occurs on the sidechain. Based on the input parameters in the request, "blockchain node 12" calls "smart contract module 25" on the sidechain to obtain relevant data and calculate the simulation results. This process is independent of the process described in "step S404" and is executed in parallel.

[0127] Step S406: The process of the "blockchain node 12" on the side chain uploading the data generated by the smart contract request. The "blockchain node 12" will first obtain the simulation result obtained from "Step S405", and then call the "communication module 24" to obtain the smart contract operation verification result triggered on the main chain in "Step S404". If the verification is successful, the "blockchain node 12" will package the generated data into a block and call the "consensus module 26" to conduct consensus among nodes. After the new block is consensus, the "blockchain node 12" will call the "storage module 27" to append the new block to the side chain.

[0128] Step S407: The same as the above "Step 308", that is, after the "blockchain node 12" on the side chain completes the upload of the new block, the "blockchain node 12" will feedback the response situation of the smart contract request to the "user 11".

[0129] A blockchain resource management method based on multi-chain collaboration provided by an embodiment of the present invention has at least the following beneficial effects:

[0130] 1. By adopting a multi-chain architecture to construct a blockchain permission management mechanism, running the permission management mechanism and the smart contract mechanism on different chains, realizing the independence of the blockchain system permission control mechanism and business rules, and reducing the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system.

[0131] 2. By introducing a permission control plug-in and a certificate-based permission authentication mechanism, realizing unified permission control for multi-level resources such as interface resources and smart contract execution in the blockchain system, and preventing the resources of the blockchain system from being illegally used.

[0132] Figure 10 It is a schematic structural diagram of a blockchain resource management device based on multi-chain collaboration provided by an embodiment of the present invention. As Figure 10 shown, a blockchain resource management device based on multi-chain collaboration proposed by an embodiment of the present invention includes:

[0133] A determination module 51, configured to determine the request type of the resource call request according to the request content of the resource call request, where the resource call request includes information of the resource caller;

[0134] An execution module 52, configured to, if the request type of the resource call request is a smart contract request, execute the smart contract requested to be executed in the resource call request locally according to the service parameters in the resource call request;

[0135] A sending module 53, configured to send the resource call request to a main chain node, where the main chain node is used to verify whether the resource caller has the execution permission of the smart contract;

[0136] A generation module 54, configured to generate a response message for the resource call request according to the execution result of the smart contract and the verification result generated by the main chain node.

[0137] The blockchain resource management device based on multi-chain collaboration provided by the embodiments of the present invention constructs a blockchain permission management mechanism in the form of a multi-chain architecture, runs the permission management mechanism and the smart contract mechanism on different chains, realizes the independence of the permission control mechanism and business rules of the blockchain system, reduces the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system, and improves the response speed of the blockchain system to transactions.

[0138] Optionally, the determining module is specifically configured to:

[0139] Determine whether the resource caller has the permission to access the resource requested to be called in the resource call request according to the latest resource access permission information stored locally, where the latest resource access permission information stored locally is obtained from the main chain node in advance;

[0140] If the resource caller has the permission to access the resource requested to be called in the resource call request, determine the request type of the resource call request according to the resource requested to be called.

[0141] Optionally, the determining module determining whether the resource caller has the permission to access the resource requested to be called in the resource call request according to the latest resource access permission information stored locally includes:

[0142] Search for the caller role type corresponding to the resource requested to be called in the latest resource access permission information stored locally;

[0143] If the role type is the same as the role type recorded in the certificate information of the resource caller, determine that the resource caller has the permission to access the resource requested to be called.

[0144] Optionally, the sending module is further configured to:

[0145] If the request type of the resource call request is a permission management request, send the resource call request to the main chain node, where the main chain node is configured to update the resource permission information requested to be managed in the resource call request according to the resource call request.

[0146] Optionally, the device further includes an acquisition module, configured to acquire and save the updated resource access permission information pushed by the main chain node if the resource permission information updated by the main chain node includes resource access permission information.

[0147] Optionally, the sending module is specifically configured to:

[0148] If the request type of the resource call request is a permission management request, the identity information of the local side chain node and the resource call request are sent to the main chain node, where the main chain node is used to update the resource permission information requested to be managed in the resource call request according to the identity information of the side chain node and the resource call request.

[0149] The embodiments of the device provided by the embodiments of the present invention can specifically be used to execute the processing flows of the above method embodiments, and their functions will not be described in detail here. Reference can be made to the detailed descriptions of the above method embodiments.

[0150] It should be noted that the blockchain resource management method and device based on multi-chain collaboration provided by the embodiments of the present invention can be used in the financial field, and can also be used in any technical field other than the financial field. The embodiments of the present invention do not limit the application fields of the blockchain resource management method and device based on multi-chain collaboration.

[0151] Figure 11 It is a schematic structural diagram of a blockchain resource management device based on multi-chain collaboration provided by an embodiment of the present invention. As Figure 11 shown, a blockchain resource management device based on multi-chain collaboration proposed by an embodiment of the present invention includes:

[0152] An obtaining module 61, configured to obtain a resource call request forwarded by a side chain node, where the resource call request includes information of a resource caller;

[0153] A verification module 62, configured to, if the request type of the resource call request is a smart contract request, verify whether the resource caller has the execution permission of the smart contract requested to be executed in the resource call request according to the resource permission information stored locally;

[0154] A sending module 63, configured to send the verification result to the side chain node, where the side chain node is used to generate response information of the resource call request according to the verification result and the execution result of the smart contract on the side chain node.

[0155] The blockchain resource management device based on multi-chain collaboration provided by the embodiments of the present invention constructs a blockchain permission management mechanism in the form of a multi-chain architecture, runs the permission management mechanism and the smart contract mechanism on different chains, realizes the independence of the permission control mechanism and the business rules of the blockchain system, reduces the impact of the blockchain permission mechanism on the scalability and performance of the blockchain system, and improves the response speed of the blockchain system to transactions.

[0156] Optionally, the verification module is further configured to: if the request type of the resource call request is a permission management request, verify whether the side chain node has the permission to manage the resource permission information requested to be managed in the resource call request according to the resource permission information stored locally;

[0157] The apparatus further includes: an update module, configured to update the resource permission information requested to be managed in the resource call request according to the resource call request if the side chain node has the permission to manage the resource permission information requested to be managed in the resource call request.

[0158] Optionally, the apparatus further includes:

[0159] A push module, configured to push the resource access permission information to the side chain node if the updated resource permission information includes resource access permission information.

[0160] The embodiments of the apparatus provided in the embodiments of the present invention can specifically be used to execute the processing flows of the above method embodiments, and their functions will not be elaborated here. Reference can be made to the detailed descriptions of the above method embodiments.

[0161] It should be noted that the blockchain resource management method and apparatus based on multi-chain collaboration provided in the embodiments of the present invention can be used in the financial field and can also be used in any technical field other than the financial field. The embodiments of the present invention do not limit the application fields of the blockchain resource management method and apparatus based on multi-chain collaboration.

[0162] Figure 12 The entity structure diagram of the electronic device provided in an embodiment of the present invention is shown as Figure 12 shown. The electronic device may include: a processor 701, a communications interface 702, a memory 703, and a communication bus 704. Among them, the processor 701, the communications interface 702, and the memory 703 communicate with each other through the communication bus 704. The processor 701 can call the logic instructions in the memory 703 to execute the method described in any of the above embodiments.

[0163] In addition, when the logical instructions in the above-mentioned memory 703 are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0164] This embodiment discloses a computer program product. The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the methods provided in the above-mentioned method embodiments.

[0165] This embodiment provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. The computer program causes the computer to execute the methods provided in the above-mentioned method embodiments.

[0166] Those skilled in the art should understand that the embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0167] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0168] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to work in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the functions specified in one process Figure 1 or a plurality of processes and / or blocks Figure 1 or a plurality of blocks.

[0169] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are executed on the computer or other programmable apparatus to produce a computer-implemented process, and thus the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in one process Figure 1 or a plurality of processes and / or blocks Figure 1 or a plurality of blocks.

[0170] In the description of this specification, the descriptions with reference to the terms "one embodiment", "a specific embodiment", "some embodiments", "for example", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0171] The above specific embodiments have further elaborated on the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above are only specific embodiments of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the protection scope of the present invention.

Claims

1. A blockchain resource management method based on multi-chain collaboration, characterized in that Executed by a side-chain node, the method includes: Determine the request type of the resource invocation request according to the request content of the resource invocation request, where the resource invocation request includes information about the resource invoker. If the request type of the resource invocation request is a smart contract request, execute the smart contract requested to be executed in the resource invocation request locally according to the service parameters in the resource invocation request. Send the resource invocation request to the main-chain node, where the main-chain node is used to verify whether the resource invoker has the execution permission of the smart contract and send the generated verification result to the side-chain node. Generate the response information of the resource invocation request according to the execution result of the smart contract and the verification result generated by the main-chain node. If the request type of the resource invocation request is a permission management request, send the resource invocation request to the main-chain node, where the main-chain node is used to update the resource permission information to be managed in the resource invocation request according to the resource invocation request.

2. The method according to claim 1, characterized in that The determining the request type of the resource invocation request according to the request content of the resource invocation request includes: Determine whether the resource invoker has the permission to access the resource requested to be invoked in the resource invocation request according to the latest resource access permission information stored locally, where the latest resource access permission information stored locally is obtained from the main-chain node in advance. If the resource invoker has the permission to access the resource requested to be invoked in the resource invocation request, determine the request type of the resource invocation request according to the resource requested to be invoked.

3. The method according to claim 2, characterized in that, The determining whether the resource invoker has the permission to access the resource requested to be invoked in the resource invocation request according to the latest resource access permission information stored locally includes: Search for the invoker role type corresponding to the resource requested to be invoked in the latest resource access permission information stored locally. If the role type is the same as the role type recorded in the certificate information of the resource invoker, determine that the resource invoker has the permission to access the resource requested to be invoked.

4. The method according to claim 1, wherein If the resource permission information updated by the main-chain node includes resource access permission information, the method further includes: Obtain and save the updated resource access permission information pushed by the main-chain node.

5. The method according to claim 1, wherein The sending the resource invocation request to the main-chain node if the request type of the resource invocation request is a permission management request includes: If the request type of the resource invocation request is a permission management request, send the identity information of the local side-chain node and the resource invocation request to the main-chain node, where the main-chain node is used to update the resource permission information to be managed in the resource invocation request according to the identity information of the side-chain node and the resource invocation request.

6. A blockchain resource management method based on multi-chain collaboration, characterized in that, Executed by the main-chain node, the method includes: Obtain the resource invocation request forwarded by the side-chain node, where the resource invocation request includes information about the resource invoker. If the request type of the resource invocation request is a smart contract request, verify whether the resource invoker has the execution permission of the smart contract to be executed in the resource invocation request according to the resource permission information stored locally; Send the verification result to the side chain node, where the side chain node is used to generate the response information of the resource invocation request according to the verification result and the execution result of the smart contract on the side chain node; If the request type of the resource invocation request is a permission management request, verify whether the side chain node has the permission to manage the resource permission information requested to be managed in the resource invocation request according to the resource permission information stored locally; if the side chain node has the permission to manage the resource permission information requested to be managed in the resource invocation request, update the resource permission information requested to be managed in the resource invocation request according to the resource invocation request.

7. The method according to claim 6, characterized in that, The method further includes: If the updated resource permission information includes resource access permission information, push the resource access permission information to the side chain node.

8. A blockchain resource management device based on multi-chain collaboration, characterized in that, Configured in the side chain node, the device includes: A determination module, configured to determine the request type of the resource invocation request according to the request content of the resource invocation request, where the resource invocation request includes information of the resource invoker; An execution module, configured to, if the request type of the resource invocation request is a smart contract request, execute the smart contract to be executed in the resource invocation request locally according to the service parameters in the resource invocation request; A sending module, configured to send the resource invocation request to the main chain node, where the main chain node is used to verify whether the resource invoker has the execution permission of the smart contract and send the generated verification result to the side chain node; A generation module, configured to generate the response information of the resource invocation request according to the execution result of the smart contract and the verification result generated by the main chain node; The sending module is further configured to: if the request type of the resource invocation request is a permission management request, send the resource invocation request to the main chain node, where the main chain node is used to update the resource permission information requested to be managed in the resource invocation request according to the resource invocation request.

9. A blockchain resource management device based on multi-chain collaboration, characterized in that, Configured in the main chain node, the device includes: An acquisition module, configured to acquire the resource invocation request forwarded by the side chain node, where the resource invocation request includes information of the resource invoker; A verification module, configured to, if the request type of the resource invocation request is a smart contract request, verify whether the resource invoker has the execution permission of the smart contract to be executed in the resource invocation request according to the resource permission information stored locally; A sending module, configured to send the verification result to the side chain node, where the side chain node is used to generate the response information of the resource invocation request according to the verification result and the execution result of the smart contract on the side chain node; The verification module is further configured to: if the request type of the resource call request is a permission management request, verify whether the side chain node has the permission to manage the resource permission information requested to be managed in the resource call request according to the resource permission information stored locally; An update module, configured to update the resource permission information requested to be managed in the resource call request according to the resource call request if the side chain node has the permission to manage the resource permission information requested to be managed in the resource call request.

10. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 or claims 6 to 7 are implemented.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 5 or claims 6 to 7 are implemented.

Images